hi miller,
since i have to rewrite the garray locks once again, can you estimate, when you will finish the implementation of the t_garrays? once again it's easier to rewrite them than porting ... it's similar for thomas grill's garray_update functions ... i'd suggest we try to meet on irc during the next few days (probably evening for me, morning for you :) to discuss if and how we can handle this ... i'd like to improve the threaded soundfiler soon, but without knowing what will happen to the t_garrays in future, its probably only a waste of my time ...
usually, sitting at my computer i'm logged into the #dataflow irc channel, so it would be nice if you could try to contact me there ...
thanks ... tim
Hi Tim,
I'm hoping to get it to a point where it won't change much by the time 0.39 is stable... judging from past experience, that might be another 3 months or so.
I'm now worried that, having unified garrays and arrays-in-data, we might need an entirely different buffering scheme for handling 8-, 16- and 32-bit arrays, especially once the 64 bit version of Pd comes into wider use. But also, 32-bit arrays are probably overkill for buffering images. I'm hoping to experiment with unifying the "tilde" stuff with image I/O this summer, which will bring this question to a head.
cheers Miller
On Sat, May 21, 2005 at 06:58:11PM +0200, Tim Blechmann wrote:
hi miller,
since i have to rewrite the garray locks once again, can you estimate, when you will finish the implementation of the t_garrays? once again it's easier to rewrite them than porting ... it's similar for thomas grill's garray_update functions ... i'd suggest we try to meet on irc during the next few days (probably evening for me, morning for you :) to discuss if and how we can handle this ... i'd like to improve the threaded soundfiler soon, but without knowing what will happen to the t_garrays in future, its probably only a waste of my time ...
usually, sitting at my computer i'm logged into the #dataflow irc channel, so it would be nice if you could try to contact me there ...
thanks ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
hi Miller,
is abstracting the dsp graph into a modular design part of the plan? Things like polyphonic instruments with dynamic voice allocation, loading patches without breaking the sound, etc. are really tough when the whole thing has to be recalculated.
Krzysztof
Miller Puckette wrote: ...
also, 32-bit arrays are probably overkill for buffering images. I'm hoping to experiment with unifying the "tilde" stuff with image I/O this summer, which will bring this question to a head.
HI Krzysztof,
I can't say as of yet that I have a definite plan for any of this... that's why it takes me so long to do anything... but I'll see if there's an easy way to do this.
cheers Miller
On Mon, May 23, 2005 at 11:12:28AM +0200, Krzysztof Czaja wrote:
hi Miller,
is abstracting the dsp graph into a modular design part of the plan? Things like polyphonic instruments with dynamic voice allocation, loading patches without breaking the sound, etc. are really tough when the whole thing has to be recalculated.
Krzysztof
Miller Puckette wrote: ...
also, 32-bit arrays are probably overkill for buffering images. I'm hoping to experiment with unifying the "tilde" stuff with image I/O this summer, which will bring this question to a head.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi all, i'm also very much interested in a way to have smooth loading and scripting of DSP objects. I tried once to divide the graph into one instance per root patcher, but i ended up with changing practically everything and got totally lost in the code. Maybe, before introducing such a radical change there are ways to make it possible with workarounds and optimizations
- First, there is the new low priority callback in the devel branch. It was motivated by the wish to do things whenever there is time to.... e.g. adding objects into a patch. It should be possible to open a new patcher, drop in the objects and after all have been loaded, loadbang/dsp the whole thing into existence. I'm currently trying to do that in dyn~, but it should also be possible in PD itself.
- Second, when profiling the creation of DSP objects (on OSX) i found that most of the time is wasted with memory allocation and disposal (above all in ugen_done_graph, ugen_add etc.). It should be possible, to cleverly reuse already allocated memory if the change in the graph hasn't been too drastic.
best greetings, Thomas
HI Krzysztof,
I can't say as of yet that I have a definite plan for any of this... that's why it takes me so long to do anything... but I'll see if there's an easy way to do this.
cheers Miller
On Mon, May 23, 2005 at 11:12:28AM +0200, Krzysztof Czaja wrote:
hi Miller,
is abstracting the dsp graph into a modular design part of the plan? Things like polyphonic instruments with dynamic voice allocation, loading patches without breaking the sound, etc. are really tough when the whole thing has to be recalculated.
Krzysztof
Miller Puckette wrote: ...
also, 32-bit arrays are probably overkill for buffering images. I'm hoping to experiment with unifying the "tilde" stuff with image I/O this summer, which will bring this question to a head.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
hi Thomas,
Thomas Grill wrote: ...
- First, there is the new low priority callback in the devel branch. It
was motivated by the wish to do things whenever there is time to.... e.g. adding objects into a patch. It should be possible to open a new patcher, drop in the objects and after all have been loaded, loadbang/dsp the whole thing into existence. I'm currently trying to do that in dyn~, but it should also be possible in PD itself.
everything in one go, or by scheduling fine-grained tasks?
Have you considered building the new graph in the background, then rendering the new dsp chain into a ``back buffer''?
Anyway, I am afraid that low priority scheme does not cover voice allocation, due to unbounded latency.
Krzysztof
Hi Krzysztof,
- First, there is the new low priority callback in the devel branch.
It was motivated by the wish to do things whenever there is time to.... e.g. adding objects into a patch. It should be possible to open a new patcher, drop in the objects and after all have been loaded, loadbang/dsp the whole thing into existence. I'm currently trying to do that in dyn~, but it should also be possible in PD itself.
everything in one go, or by scheduling fine-grained tasks?
the low priority callbacks have 3 modes, one of which is using as much time as available in the given timeslice. In most of the cases this means several iterations, though.
Have you considered building the new graph in the background, then rendering the new dsp chain into a ``back buffer''?
Depending on the kind of objects it's not merely the DSP graph that consumes time... it's also very much the creation of the objects. For safe DSP scripting the key seems to be a combination of throttled creation of objects (loading of patchers), which implies building the DSP chain in the background, and of having partitioned DSP chains, ideally auto-adjusting in size (at least one for each root patcher, but if that becomes too large, also split according to subpatchers/abstractions) Additionally, currently all major data structures in PD are linked lists that become slow as soon as many objects are involved (easy to check with dyn~). It would be advantageous to switch to b-trees or the other non-O(n) structures.
Anyway, I am afraid that low priority scheme does not cover voice allocation, due to unbounded latency.
That's true... the only way to account for that without crackling is to have enough spare voices in the backhand.
best greetings, Thomas
thanks Thomas, I would better look at your code soon...
Thomas Grill wrote: ...
Anyway, I am afraid that low priority scheme does not cover voice allocation, due to unbounded latency.
That's true... the only way to account for that without crackling is to have enough spare voices in the backhand.
let's assume first it is too sad to be true... switching instruments in a massively multi-timbral setup should be instantaneous too. Thus, currently, the number of voices a synth patch has to pre-allocate is number of instruments times number of voices per instrument. In many typical applications, this is far too many. It would be much easier, if a once computed dsp chain of an instrument definition could be reused as a voice-creating template.
Krzysztof
let's assume first it is too sad to be true... switching instruments in a massively multi-timbral setup should be instantaneous too. Thus, currently, the number of voices a synth patch has to pre-allocate is number of instruments times number of voices per instrument. In many typical applications, this is far too many. It would be much easier, if a once computed dsp chain of an instrument definition could be reused as a voice-creating template.
Oh sure... sorry for the negativity... i was just talking about goals that are easier to reach. No doubt, a patcher oriented modular design would be best, although not as cache-friendly as a monolithic chain.
best, Thomas
-
Krzysztof Czaja -
Miller Puckette -
Thomas Grill -
Tim Blechmann