On Ven Oct 26 1:26 , Roman Haefeli sent:
On Thu, 2007-10-25 at 16:22 -0400, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Roman Haefeli wrote:
the main problem with dynamic patching is, that it is very likely, that
it causes audio drop-outs.
It wouldn't take much code to introduce something that can wrap dynamic
patching in a way that prevents any DSP recompilation at the wrong moment.
E.g. If I have a patch that has 40 DSP objects, and then I instantiate an
abstraction that has 10 dsp objects, 20 times, this recompiles DSP 20
times, taking a total of 10*(40+(10+10*20)/2) = 1450 dsp_add calls. If the
dynamic creations dominate, the time increases quadratically, which is one
kind of "gets bad quite quickly".
Bracketing a bunch of dynamic object creations with a dsp-disable /
dsp-enable pair, you just recompile once at the end, in the above example
totalling to 40+10*20 = 240 dsp_add calls, which is exactly the size of
the dsp graph you have at the end.
that is what i do in netpd since last change. whenever a patch is
loaded, it is not openen per message anymore but created dynamically as
an abstraction. i found out, that it takes _much_ less time, if dsp is
turned off before and turned on after creating it. this is probably the
difference between what you describe as linear and quadratic increase.
Getting any better than linear time is somewhat harder, especially for pd,
but linear is already much better than quadratic.
especially when creating ~-objects, the dsp graph needs to be
recompiled, which requires some cpu power.
... uninterruptible cpu power.
but if patches don't expect the dsp to be updated immediately, the job
could be spread over several logical time blocks.
don't know how to do that. there is no way in pd to tell how much behind
schedule pd is with computing, or is there? anyway, in the case of netpd
it wouldn't help anyway, since complete patches are created as single
abstractions. i wouldn't know how to break that into smaller chunks.
there was a thread: slowly load patches/abs without dropout
http://lists.puredata.info/pipermail/pd-list/2007-01/046107.html
the attached patch reads and creates a patch slowly triggered by a metro. as far as i remember i didn't implemented a correct array-creation.
eni