[PD-dev] Re: array locks

Thomas Grill gr at grrrr.org
Tue May 24 14:31:41 CEST 2005

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,

> 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 at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

More information about the Pd-dev mailing list