Expected behavior of use_sched_ahead_time?

Support, Help & Resources
1

I’m not sure anymore how this thing is supposed to work. I was expecting use_sched_ahead_time to delay the run of the loop with given amount of time, but it seems to affect the next sleep value in a loop in curious ways. Examples from the help:

live_loop :foo do
  use_sched_ahead_time 1
  play 70                
  sleep 1 # Effectively 0.5 in first run, after that 1.0?
end

live_loop :foo do
  use_sched_ahead_time 0.5
  play 82
  sleep 1 # Same for each run
end

When testing with multiple sleeps the effect is more obvious:

live_loop :foo do
  use_sched_ahead_time 1.0
  play 60
  sleep 1.0 # 0.5 in first run?
  play 60
  play 65
  play 69
  sleep 1.0 # But no effect here whatsoever
end

Value 0.5 seems to work (as I would expect) but all other values seem mess with the first sleep in the loop. What is happening here? All I want to do is to delay the start of some loops.

2

Can you not put a sleep ahead of the sequence you want to delay? And if it breaks your other loops can you not do it just once in the to be delayed loop possibly with the delay: parameter of live_loops?

3

For what you are trying to do you should use the delay: opt in a live loop.
delay: Initial delay in beats before the live_loop starts. Default is 0
eg

play 72,release: 0.2
live_loop :foo,delay: 0.5 do
  
  play 60
  sleep 1.0 
  play 60
  play 65
  play 69
  sleep 1.0
end

note 0.5 beat delay between first note and the liveloop output.

4

Thanks, but I didn’t just want the delay, but also run some heavier computing before the synths start.

I want to understand how that thing actually works. Why does the value 1.0 effectively change the first sleep value to 0.5?

If you look at the log to that earlier example with some chords, it produces this:

{run: 38, time: 0.0, thread: :live_loop_foo}
 └─ synth :beep, {note: 60.0}
 
{run: 38, time: 0.5001, thread: :live_loop_foo} <-------- ?? 0.5 ??
 ├─ synth :beep, {note: 60.0}
 ├─ synth :beep, {note: 65.0}
 └─ synth :beep, {note: 69.0}
 
{run: 38, time: 1.5001, thread: :live_loop_foo} <------------- ?? 1.0 ??
 └─ synth :beep, {note: 60.0}

If you do value 0.4 for the sched ahead it effectively add 0.1 to the first sleep. Why is the 0.5 only value that doesnt mess up the timing? Just wondering why it does what it does :slight_smile:

5

For a full treaty of how the schedule ahead time works check out this paper: https://www.doc.ic.ac.uk/~dorchard/publ/farm14-sonicpi.pdf

In brief, it affects the outgoing time stamps and also affects how much “breathing” room the internal timing system has. It essentially adds latency to the system.

It shouldn’t be used unless you’re experiencing load issues on your system (you can increase it in this case) or for threads you want to be as responsive as possible (in which case use use_real_time).

I’m not quite sure what you’re trying to achieve here, but I’m pretty sure use_sched_ahead_time is unlikely to be part of a solution.

1 Like