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