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
slowlyopen.pd
Description: Binary data
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
