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
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
On Fri, 26 Oct 2007, Roman Haefeli wrote:
a) it is very hard to do that in pd, since message to canvasses are different from the lines in the pd-file?
No, they are not different. Lines in the pd-file are interpreted as message to a canvas using #X, a message to [canvasmaker] using #N, or a message to an array using #A.
"#N canvas" and "#X restore" will change the receiver of the receive-symbol #X so that it points to the correct canvas at all time. They use pd_pushsym and pd_popsym, which maintain a list of receivers for each receive-symbol in which only the last element is a currently active receive-symbol.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, 26 Oct 2007, Enrique Erne wrote:
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.
So, why would that be more realtime-safe? I don't understand.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Oct 27, 2007, at 1:59 AM, Mathieu Bouchard wrote:
On Fri, 26 Oct 2007, Enrique Erne wrote:
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.
So, why would that be more realtime-safe? I don't understand.
sorry, i didn't want to say that it is realtime safe. my test failed as you see when you continue to read the thread. i was just replying to :
complete patches are created as single abstractions. i wouldn't know how to break that into smaller chunks.
and i think it looks nice to see how the patch slowly builds up :-)
eni