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.
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.
Of course the first solution I mentioned is best applied first, and then only bother with the latter if you need more realtimeness.
pd-objects don't have a unique identifier, but they are just counted by their creation order. when a certain objects is removed, all subsequently created objects change their address.
It's not hard to add a method to the canvas class that will delete whichever range of indices of objects that you want from a patch.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
