[PD-dev] Re: array locks
gr at grrrr.org
Tue May 24 14:31:41 CEST 2005
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.
> HI Krzysztof,
> I can't say as of yet that I have a definite plan for any of this...
> why it takes me so long to do anything... but I'll see if there's an
> way to do this.
> 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.
>> Miller Puckette wrote:
>>> also, 32-bit arrays are probably overkill for buffering images. I'm
>>> to experiment with unifying the "tilde" stuff with image I/O this
>>> will bring this question to a head.
>> PD-dev mailing list
>> PD-dev at iem.at
> PD-dev mailing list
> PD-dev at iem.at
More information about the Pd-dev