Hi,
I have never understood how to control when a modification in a live_loop is taken into account
I guess when the run button is pressed. right ?
Would it be possible to set as in ableton a delay before the changes are taken into account ?
let say we change, press the run button and the next 4 beats, the changes will be taken into account
hope i’m clear. not sure 
Are you thinking of a delay per loop, or across everything?
across everything maybe but often they are synchronised no ? Do you see what i mean with the ableton allusion ?
Well, I’ve never used Ableton anything, so not quite 
Anyway, if you’re thinking the delay applies to everything, then easy - check out the documentation for set_sched_ahead_time!
no this is not what i mean. Not question of delay at all…
In ableton, you launch clips and then if you launch a new clip or stop some clips, these changes are taken into account the next 4 beats (or another length). So you are sure all changes will begin at the next four beats.
So is there a way to get this in sonic pi ? Right now, i don’t think.
In sonicpi, it’s quite a bit hard to be sure the changes will be taken into account when you press the run button. You have to be very acurate.
Well, by delay I mean a scheduled delay - I assume you want changes to take effect after a delay of X beats…
If these changes while live coding are inside live_loops, then these will of course have their own sleeps or sync commands inside them that they will execute. So code changes in each live_loop are tied both to sched_ahead_time as well as the timespan of the loop.
The commands at and time_warp do let you schedule code into the future, but the time at which they are triggered to then schedule this code will still be affected by sleeps or syncs if they are inside a live_loop.
If a loop’s timespan is short, then it can be more challenging to know whether you triggered code changes with Run within the right loop cycle. Is this what you’re getting at?
ok @ethancrawford thanks for these explanations. Sorry not to have understood you :-). there is a kind of delay in my mind…
In order to catch the whole thing, would you have a bit of code to illustrate your thoughts ?
Cheers
hey nib can u further explain what u mean i am sure there is a work around
I think what he means is roughly what I refer to in the last sentence of my last reply:
So for example, you have some code running in a live_loop which has a certain timespan, and you hit run after typing some changes in the live_loop at such a time that the new run trigger possibly ends up happening just after the loop has cycled around - in which case your changes wait almost another full cycle of the loop before taking effect.
Whereas if you trigger a run just before the loop has cycled around, your code change takes effect without having to wait quite as long.
Let me know if I understand it correctly @nlb 
well understood @ethancrawford.
in some live performances you see that the spi user tries several times alt + r before getting what they want.
use_bpm 60
live_loop :foo do
play :c7
sleep 0.25
end
live_loop :foo2 do
play :e
sleep 1
end
it’s harder to be accurate with the first loop. So my original question was is it possible to set a parameter that force sonic pi to take into account the changes each 4 beats.
@holz : i can’t go further i’m exhausted
Not really, with any kind of dedicated sonic-pi command or parameter. As holz has suggested there are probably ways to work around the issue, so that you can schedule changes to be synchronised in a desired manner, though I’d have to take this up tomorrow as it’s getting late here 
I’m happy to pass the baton to someone else if they can chip in
Well, I think this boils down to the question how you synchronize live loops.
Here is an example involving a pad and a bass line. Each one takes 4 bars; if you stop one or the other (manually or somehow automated) you always want to start them at the same time, which can be achieved by synchronizing both loops with a four bar loop.
Probably there are other ways but I have made good experiences with this technique.
Here is another example - musically more advanced but synchronization-wise simpler - with several loops being synchronised by a metronome.
Let me know if this helps. Or … maybe I misunderstood the question?
thanks for all your answers. i will try them and give you some feedbacks then.
isnt this also a possible solution?
live_loop :metro do
sleep 1
end
live_loop :after_4_bars do
4.times do
sync :metro
end
play50
sleep 0.5
end