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...