Ah yes, I see what’s happening. This is due to the
sync in the first live loop being automatically placed at a lower priority to the
cue generated by the
chief live loop. This behaviour was introduced when I made this stuff deterministic - i.e. it always has the same behaviour rather than randomly doing different things.
However, I still consider it to either be a bug I’d like to fix, but if that doesn’t prove to be feasible, I’d like to be able to provide a work around by enabling people to set the priority on a thread, so that you can control the order of the behaviour manually and deterministically.
It’s also important to point out that the
sleep 0.005 won’t result in the threads being very slightly out of phase as the
sync will override this difference by simply adopting the time of the thread that calls
cue - so this is actually safe to do with respect to timing (although it does feel like a bit of a kludge!).