Hey @nlb…
I’ve hopefully cleared up Martin’s question in the other thread.
With regard to your code illustration above, I’ll try to clarify it: the reason the sample :loop_amen, beat_stretch: 2 works is because beat_stretch: 2 does not actually cause the thread to sleep for that amount of time. (Rather, it tells the sample function to play sound for that long).
Thus, the :percussion1 thread, when using the beat_stretch example, only sleeps for 1 beat in total, since there is only a single sleep 1 in that instance.
One the other hand, when using the :drum_bass_soft/:drum_snare_soft example, if we count the two sleeps after each sample, plus the one at the very end of the live_loop, that’s a total of 3 beats that the thread’s loop duration lasts - so naturally it’s still doing things while the next :cue from :goP is sent - but it doesn’t ‘hear’ that because it’s still busy, not waiting at a sync.
Note, as I understand it, even if we reduce the sleep durations so that this loop’s duration is the same as the one we want to trigger it with (the conductor loop) - so that they are both 2 beats long, we will have the same problem. This I believe is what Sam’s explanation a while back refers to:
“…for threads syncing and queueing on the same logical time, their thread ID will determine whether they are before or after.”
(@samaaron can correct me if I’m wrong).
Does that make things any clearer? let us know. It’s really valuable to understand where the documentation can be improved etc.