[PD] Array indexing for the wind and the birds

Enrique Erne pd at mild.ch
Fri Oct 26 10:13:18 CEST 2007



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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slowlyopen.pd
Type: application/octet-stream
Size: 13517 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071026/be3f358a/attachment.obj>


More information about the Pd-list mailing list