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
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
(*) referring to IOhannes' later mail, I think that that's correct, but
I'm not 100% sure without digging through the source code...