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