Hello dear experts
I have to admit that I have difficulties in understanding the live_loops (but I like them very much).
My question is exactly:
a.) is it better to start every live_loop with a sleep before making sounds/melodies or is it better to make sleeps after the sounds (or is it of no importance how to start).
b.) what does sync exactly do with sleep commands?
c.) is there an easy explanation somewhere?
Thanks a lot for your help!
Barb.
Hi there,
have you taken a look at the tutorial sections on live loops?
Hello samaaron
Thanks for your reply.
I want to give an example:
This code
live_loop :bass do
use_bpm = 60
sample :drum_heavy_kick
sleep 1
sample :drum_cymbal_pedal
sleep 0.25
sample :drum_snare_soft
sleep 0.25
sample :drum_cymbal_pedal
sleep 0.25
sample :drum_snare_soft
sleep 0.25
end
does the same than this code.
live_loop :bass do
use_bpm = 60
sample :drum_heavy_kick
sleep 1
end
live_loop :basic do
use_bpm = 60
sync :bass
sample :drum_cymbal_pedal
sleep 0.25
sample :drum_snare_soft
sleep 0.25
sample :drum_cymbal_pedal
sleep 0.25
sample :drum_snare_soft
sleep 0.25
end
I can not understand why? How does :basic know about sleep 1 from :bass???
Thanks
Hi there
The reason the basic loop delays by 1 beat before you hear anything even though both loops start together, is that the initial cue from the bass loop starting is missed by the basic loop which starts at the same time: the sync :bass command is not set up when the first :bass cue is sent, so that it is the second pass of the bass loop which allows the basic loop to proceed, when the second cue is sent and picked up by the sync :bass line.
There has been much discussion about this in this thread if you want to look into it further
Thanks robin.newman
I think all becomes a little bit clearer.
I have one more question to understand the basics
use_bpm = 60
live_loop :chief do
sample :drum_heavy_kick
sleep 1
end
live_loop :servant do
sync :chief
sleep 0.5
sample :drum_splash_soft
end
a.) the “Master” that dominates the speed with sleep 1 is live_loop :chief?
b.) when does live_loop :chief sent his cue, at the end after the sleep 1 ?
c.) the live_loop :servant has always to wait for one second/hit to start his sample?
d.) when I change the live_loop :chief to 2 samples with sleeps, when is the cue sent?
e.) is it possible to send a cue manually in live_loop ?
use_bpm = 60
live_loop :chief do
sample :drum_heavy_kick
sleep 1
sample :drum_snare_hard
sleep 1
end
live_loop :servant do
sync :chief
sleep 0.5
sample :drum_splash_soft
end
Thanks again very much!
Bar.
Not sure what your question is here as you don’t ask one.
However the servant misses the first cue as chief is issued as a cue before sync :chief is ready to receive it first time around.
This is maybe what you are expecting
live_loop :servant do
sync :chief
sleep 0.5
sample :drum_splash_soft
end
sleep 0.005 #makes sure servant is ready BEFORE chief starts
live_loop :chief do
sample :drum_heavy_kick
sleep 1
end
The effect is that the whole thing starts 0.005 beats after the run button is pushed, but the timing therafter is accurate.
You can think of it like a conductor holding up his baton to get everone ready (when run is pushed), then giving his down beat (0.005 later) when cheif starts and servant is in time with that.
Thanks a lot robin.newman
My question has been the questions a.) to e.) 
sorry for confusing you
Would you be so kind to answer because these are the basics that I am confused about …
Thank you
Bar.
OK, as far as q e and f) are concerned there are many solutions.
One way of adding another sample is to put it in a separate live_loop. This example also illustrated sending a cue from inside a live_loop
live_loop :servant do
sync :chief
sleep 0.5
sample :drum_splash_soft
end
live_loop :servant2 do
sync :p2
sample :drum_cymbal_closed
end
sleep 0.005 #makes sure servant is ready BEFORE chief starts
live_loop :chief do
sample :drum_heavy_kick
sleep 0.75
cue :p2
sleep 0.25
end
#makes sure servant is ready BEFORE chief starts
Are you sure this is necessary? I programmed it so that you don’t need fiddly sleeps like this, so if you remove it and sometimes it works and sometimes it doesn’t then that’s definitely a bug.
hmm I think it IS necessary in this example. The sync :chief is inside the live_loop not in the calling line line
live_loop :servant do
sync :chief
not
live_loop :servant,sync: :chief do
I find this doesn’t work without the short delay.
It is not the way I would personally set out this code, but I was working with the example given in the original question.
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!).
Agreed. In fact I stated in a previous post in the thread that the “bodge” time doesn’t affect the overall accuracy but merely delays the start after run is pushed by a tiny amount (in fact irrelevant compared to the default scheduled ahead time).