what's the order of execution for signal~ objects that output messages (eg env~)?
eg:
[...~] | [env~] | [print 1]
[...~] | [env~] | [print 2]
which will get printed first?
cheers d
Damian Stewart wrote:
what's the order of execution for signal~ objects that output messages (eg env~)?
eg:
[...~] | [env~] | [print 1]
[...~] | [env~] | [print 2]
which will get printed first?
depends on the order of execution in the signal objects. thus it is usually undefined which of the [env~]s will output first, unless you use order-forcing.
fgmasdr IOhannes
Thomas Grill wrote:
Am 25.09.2008 um 14:22 schrieb IOhannes m zmoelnig:
unless you use order-forcing.
... which i have never heard of... do you mind to elaborate?
i'm sure you did. it's the same technique claude had in mind and which is described in 3.audio.examples/G05.execution.order.pd
gfmasdr IOhannes
Am 25.09.2008 um 15:22 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Am 25.09.2008 um 14:22 schrieb IOhannes m zmoelnig:
unless you use order-forcing.
... which i have never heard of... do you mind to elaborate?
i'm sure you did. it's the same technique claude had in mind and which is described
in 3.audio.examples/G05.execution.order.pd
Oh well, i see. thanks, gr~~~
an easy way might be to put a [bang~] in a subpatch, so that it is triggered after the [env~ ] objects, and then connect each [env~] to the right inlet of a [f ]...then you can bang the floats with [t b b] from the [bang~]
hard off wrote:
an easy way might be to put a [bang~] in a subpatch, so that it is triggered after the [env~ ] objects, and then connect each [env~] to the right inlet of a [f ]...then you can bang the floats with [t b b] from the [bang~]
well, but the [bang~] will have the same problem: it might trigger before or after [env~] has updated it's value.
but of course you proposal to use another source for synching the outputs is the way to go.
fgmasdr IOhannes
IOhannes m zmölnig wrote:
but of course you proposal to use another source for synching the outputs is the way to go.
yeah, i kind of realised this one as well...
hm. are all the [~] objects going to trigger before or after all the message-rate objects? is that much defined? or could there be interleaved [~] and message-rate object firings? eg an [env~] fires before a [* ] which is then followed by another [env~]?
d
Damian Stewart wrote:
hm. are all the [~] objects going to trigger before or after all the message-rate objects? is that much defined? or could there be interleaved [~] and message-rate object firings? eg an [env~] fires before a [* ] which is then followed by another [env~]?
well, Pd's scheduler has a very strict definition: FIRST all the messages are triggered (e.g. by delays, user interaction, network,...), THEN all the audio computation is done. then Pd sleeps until the next tick. (let's forget about low priority calls now; i think (without looking at the code, that the sleep-time is also the time, when the gui is refreshed)
furthermore, once a message is triggered, there is no scheduling involved (unless you explicitely do so, with [delay] and friends), but rather the entire message avalanche is finished in one go.
now, signal-to-message objects _should_ accept this scheduling, by *not* sending messages in the dsp callback, but rather schedule them to the next tick (via a "[delay 0]") afaik all _internal_ objects adhere to this.
unfortunately i know of at least one _external_ object that breaks this, and this is [pack~] in zexy, which triggers a message from within the dsp-callback; so you get dsp-message-dsp interleaving here. however, i consider this a bug in [pack~] which i will fix whenever i find time. everybody making their patches dependent on this feature will be prosecuted and i cannot be made liable for whatever comes out of this.
i hope this answers your question
fgamdsr IOhannes
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not* sending messages in the dsp callback, but rather schedule them to the next tick (via a "[delay 0]") afaik all _internal_ objects adhere to this.
hm, again.. so, at what point do these invisible '[delay 0]' objects output their messages? do they end up at the 'head' or the 'tail' (so to speak) of the 'message avalanche'? or are they somewhere in the middle?
Damian Stewart wrote:
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not* sending messages in the dsp callback, but rather schedule them to the next tick (via a "[delay 0]") afaik all _internal_ objects adhere to this.
hm, again.. so, at what point do these invisible '[delay 0]' objects output their messages? do they end up at the 'head' or the 'tail' (so to speak) of the 'message avalanche'? or are they somewhere in the middle?
at the head
gmadsr IOhannes
Damian Stewart wrote:
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not* sending messages in the dsp callback, but rather schedule them to the next tick (via a "[delay 0]") afaik all _internal_ objects adhere to this.
hm, again.. so, at what point do these invisible '[delay 0]' objects output their messages? do they end up at the 'head' or the 'tail' (so to speak) of the 'message avalanche'? or are they somewhere in the middle?
at the head. always
gmadsr IOhannes
Damian Stewart wrote:
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not* sending messages in the dsp callback, but rather schedule them to the next tick (via a "[delay 0]") afaik all _internal_ objects adhere to this.
hm, again.. so, at what point do these invisible '[delay 0]' objects output their messages? do they end up at the 'head' or the 'tail' (so to speak) of the 'message avalanche'? or are they somewhere in the middle?
after the complete dsp cycle has finished, pd sleeps until next scheduled message, in this case it would wake up immediately and/or not sleep at all.
when pd wakes up, all clocks scheduled for that time are triggered 'in the order in which they were scheduled'.
so you still need order forcing if you want two [delay 0] to trigger in a particular order:
[t b b ] [delay 0] [delay 0] [print 2] [print 1]
should print 1 then 2. If it doesn't, it's a bug (either in Pd or the documentation).
btw: the chance of a non-dsp-triggered clock being scheduled for the same absolute logical time as a dsp-triggered [delay 0] clock is rather small, moreover pd will have already executed(*) that message chain before dsp starts, so all dsp [delay 0] clocks will run before any other messages.
(*) referring to IOhannes' later mail, I think that that's correct, but I'm not 100% sure without digging through the source code...
Claude
Damian Stewart wrote:
what's the order of execution for signal~ objects that output messages (eg env~)? which will get printed first?
It's undefined, unless you define it with subpatches with signal cords between them (which don't need to carry meaningful data, just the presence of a signal connection is enough to force order):
if this diagram makes any sense at all:
/
[pd first inlet~ | env~ -- print 1 outlet~ ] | / [pd second inlet~ inlet~ | env~ -- print 2 ]
this is documented somewhere, i think in a flanger example...
Claude
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
this is documented somewhere, i think in a flanger example...
It's in doc/3.audio.examples/G05.execution.order.pd and more verbose in The Book Every Pd User Can Learn A Lot Of (tm): http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html ff.
Ciao
Frank
-
Claude Heiland-Allen -
Damian Stewart -
Frank Barknecht -
hard off -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Thomas Grill