[PD-dev] Re: array locks
gr at grrrr.org
Tue May 24 23:39:51 CEST 2005
>> - 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
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.
More information about the Pd-dev