[PD] Interruption of audio / Loading sound into array

Jonathan Wilkes jancsika at yahoo.com
Mon Nov 14 23:46:28 CET 2011

>From: Mathieu Bouchard <matju at artengine.ca>
>To: Jonathan Wilkes <jancsika at yahoo.com>
>Cc: Charles Goyard <cg at fsck.fr>; "pd-list at iem.at" <pd-list at iem.at>
>Sent: Saturday, November 12, 2011 3:34 PM
>Subject: Re: [PD] Interruption of audio / Loading sound into array
>Le 2011-11-10 à 08:46:00, Jonathan Wilkes a écrit :
>> ----- Original Message -----
>>> From: Mathieu Bouchard <matju at artengine.ca>
>>> (this doesn't take ~-objects into account, who use a different execution model)
>> breadth-first?
>No. Breadth-first (queueing) is the execution model of t_clock components, which are central to [delay], [pipe], [metro], and other such things.
>I say that breadth-first is queueing, because if you replace every connection by a generic message pipe that does the same to messages as [pipe 0] does to floats, then a tree (of objects and connections) gets traversed breadth-first, as anything down gets delayed to after the current stack of things is done with, in the t_clock queue of things to do «now».
>However, the DSP uses a model in which data is flowing more regularly, such that order of execution often does not matter, as for example, if I take data from [osc~] into both an [expr~] and a [cpole~], and from both of them into a [*~], then the [*~] will get the same data regardless of whether [expr~] or [cpole~] gets executed first.
Ok.  It's hard for me to differentiate that from breadth-first, probably because I have a hard time reading the 
linetraverser c code (or any c code really) and figuring out from it what the rules are for ordering the signal objects 
in the DSP graph.


> The only place where this breaks, is if a given DSP order causes a 1-block delay on certain send/receive or throw/catch tasks. And also dsp loops are forbidden.
>| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

More information about the Pd-list mailing list