On Fri, 2007-10-26 at 10:13 +0200, Enrique Erne wrote:
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
didn't that thread end with the conclusion, that
a) it is very hard to do that in pd, since message to canvasses are different from the lines in the pd-file?
b) this is something that should rather managed by pd itself and not in userspace?
and still, if you do it in userspace, there is no way to tell beforehand, how many objects you can create in a certain amount of time without getting dropouts. that means, if you really want to avoid drop-outs, you would have to do it very slowly, probably so slowly, that it takes ages to recreate a whole netpd patch. if there'd be a way to create constantly as many objects so that pd is just on the edge of having a dropout, but doesn't, then it would _might_ be worth to do it in userspace.
roman
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de