# Issues with missing the timing

**URL:** <https://in-thread.sonic-pi.net/t/issues-with-missing-the-timing/2370>\
**Category:** Support, Help & Resources\
**Created:** [May 8, 2019, 12:21pm UTC](https://in-thread.sonic-pi.net/t/issues-with-missing-the-timing/2370 "2019-05-08T12:21:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![hyphz](https://avatars.discourse-cdn.com/v4/letter/h/d07c76/32.png) [@hyphz](https://in-thread.sonic-pi.net/u/hyphz)\
**Post date:** [May 8, 2019, 12:21pm UTC](https://in-thread.sonic-pi.net/t/issues-with-missing-the-timing/2370/1 "2019-05-08T12:21:06Z")

</div>

I’ve tried a couple of experiments with sonicpi, but I’ve had a recurring problem.

Say I create a live loop called `bar`, and then I write other live loops that `sync :bar`. The synchronization will work but with one problem. Even if the `sleep` calls in the other live loops add up to the same as the `sleep` call in `bar`, sometimes it seems the other loops take a fraction of a second longer, miss the `sync` and have to wait for the next one. So at random times the other live loops will go silent for a bar.

For example:

```ruby

live_loop :a do
  use_synth :prophet
  sync :bar
  play :F3
  sleep 1
end

live_loop :bar do
  sample :bd_haus
  sleep 0.5
  sample :sn_dolf
  sleep 0.5
end

```

The note should play every bar (1 time step) but actually it plays only once every two bars because it misses the timing every other bar. Removing the `sleep` from `:a` solves this but means that the last note in a bar has to be constantly written as a special case in loops, etc.

I’m familiar with this as a thread synchronization issue in most programming languages but it seems particularly harsh in live coding music. Is there any way to prevent or work around this?

---

<div class="post-metadata">

**Author:** ![ethancrawford](https://avatars.discourse-cdn.com/v4/letter/e/a88e4f/32.png) [@ethancrawford](https://in-thread.sonic-pi.net/u/ethancrawford)\
**Post date:** [May 8, 2019, 12:56pm UTC](https://in-thread.sonic-pi.net/t/issues-with-missing-the-timing/2370/2 "2019-05-08T12:56:18Z")

</div>

Hello @hyphz!

You’re in luck, there are some detailed discussions about this issue 😉 -

> [@Using :sync with live\_loops](http://in-thread.sonic-pi.net/t/using-sync-with-live-loops/172):
>
> I’m curious to see what people’s thoughts are on the best way to use :sync with multiple threads. I have seen it used outside the block of code, following the name of a live\_loop, inside the block of code as well as using cue :tick inside a block of code and then syncing with :tick. The differences seem to be in when you start the program, certain threads have to run before others sync up with it and also the length of time it takes for a change to happen in a thread that has been synced with a…

> [@Live loops Sync questions slight\_smile](http://in-thread.sonic-pi.net/t/live-loops-sync-questions/1172):
>
> Hi everybody, I always have troubles with sync in sonic pi… if somebody can explain why this following code do run as it runs, it would be kind ! use\_bpm 120 beats\_per\_bar = 4 ############################### TOOLS ############################### live\_loop :metronome do use\_synth :beep play :a4, release: 0.5 sleep 1 end live\_loop :\_1\_bar do use\_synth :beep play :as5, release: 0.5 sleep beats\_per\_bar # the cue is sent ONLY NOW /frowning so sad no ? end live\_loop :\_4\_bars do sleep b…

One of the best ways I think of avoiding the undesired delay is to use the `sync:` opt of `live_loop`. Ie:

```ruby
live_loop :bar, sync: :a do
...

```

That way, your loop will sync before it’s about to start, and from then on, just plays without syncing further. There is a small gotcha though: it will only sync on cues _after_ they have happened - so while the two loops would be in time, it would effectively wait for one iteration of loop :a before starting loop :bar.  
(There are various comments in the second thread mentioned above about minimising this ‘side-effect’ - and also a very helpful diagram about halfway down that I think explains the two approaches to syncing threads well).  
Feel free to have a read through those threads and ask us any further questions you might still have.

---

<div class="post-metadata">

**Author:** ![nordicwing](https://avatars.discourse-cdn.com/v4/letter/n/ea666f/32.png) [@nordicwing](https://in-thread.sonic-pi.net/u/nordicwing)\
**Post date:** [July 23, 2025, 10:31pm UTC](https://in-thread.sonic-pi.net/t/issues-with-missing-the-timing/2370/3 "2025-07-23T22:31:15Z")

</div>

the problem of sync opt is it won’t guarantee a sync if you modify some sleep interval between the two live\_loop definitions after they start. Meanwhile the time issue of sync command makes it useless in most of the cases without hacking with sleep numbers.