On Fri, 26 Oct 2007, Roman Haefeli wrote:
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.
The problem with that is that there is no way to figure out beforehand that the dsp was on, so you can't know for sure that it wasn't meant to be off, and I usually have it off.
this is probably the difference between what you describe as linear and quadratic increase.
yes, but if you instantiate several abstractions and turn the dsp on/off between instantiations, you are still in quadratic time, albeit a much milder (faster) form thereof. I can show you the math next time I see you... with simple pictures.
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.
That's a much harder solution, that involves tricky modifications to pd/src/d_ugen.c. Much harder than a (clean version of) the first solution. I haven't really looked into it, so I can't really tell you whether it makes sense and exactly how hard it'd be.
there is no way in pd to tell how much behind schedule pd is with computing, or is there?
Yes, use [realtime] and [timer] and [-].
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.
No, the backgrounding of the dsp recompilation is something that has to be written in C and that shouldn't affect your patches any further than ensuring that they're ok with a small logical-time delay whenever recompiling the dsp (turning the dsp on explicitly, could be exempted from that delay)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada