Need help with sync in loops

[nlb]

Hello,

live_loop :foo do
      play :e4, release: 0.5
      sleep 4
      # the cue message is sent now ?!
    end

    live_loop :bar do
      sync :foo
      sample :bd_haus
      sleep 1
    end

Can somebody explain how to do for this two loops start when the play button is pressed and not after a sleeping of 4 ?

i have read the doc but i’m lost and confused how this work…

thanks !

[Martin]

Hi,

as far as I understood, the synchronisation is very strict since version 3. This means: a sync event will only be considered as one if it is in the past, in other words: the first run of :foo will not sync :bar.

It depends a bit on what you want to do, but one option is to introduce an extra metronome loop (I sometimes have even more* with differnt length depending on the musical context):

live_loop :metro do
  sleep 1
end

live_loop :foo, sync: :metro do
  play :e4, release: 0.5
  sleep 4
end

live_loop :bar, sync: :metro do
  sample :bd_haus
  sleep 1
end

• See https://github.com/mbutz/sonicpi-leuphana-ws1718/blob/master/session-04/synchronisation-of-live-loops.rb for some other examples.

[nlb]

@Martin

live_loop :metro do
  sleep 1
end

live_loop :foo, sync: :metro do
  play :e4, release: 0.5
  sleep 4
end

live_loop :bar, sync: :metro do
  sample :bd_haus
  sleep 1
end

Thanks for this explanation. So we have to wait for one beat and then the foo and bar loops are launched.
it’s a bit confusing and the doc does not seem to clearly explain this.

How can i have my code coloured in this forum ???

i’m carrying on some other tests…

[Martin]

Yes, exactly, you will have to wait one beat (unless you let :metro sleep shorter).

You might want to have a look at this discussion which also discusses this behaviour.

Music now stops unexpectedly (possibly due to updating from v2.11.1 to v3.1?)

Hi, I would suggest reducing the size of the program until it starts working again - and then at that point you might start to get an idea of where it goes wrong. If you’re able to create a short example of a bug I’d be very happy to look into fixing it. Additionally, be aware that between v2 and v3 cue and sync were rewritten to make them fully deterministic. In v2 and before they had race conditions which meant that the behaviour could change with successive runs. It’s quite likely that thi…

Use 3 backticks at the beginning and at the end of a block of code to highlight it. A single backtick is for inline code.

[nlb]

ok thanks for the tip to colour the code

[kniknoo]

I run into this a lot. Try putting the sync at the end of a loop instead of the beginning. That way it isn’t waiting on the first run.

[nlb]

don’t understand ? some code to illustrate your mind ?

[kniknoo]

Like this

live_loop :foo do
  #cue sends here
  play :e4, release: 0.5
  sleep 4
end

live_loop :bar do
  #loop does not wait, plays immediately
  sample :bd_haus
  sleep 1
  #loop will wait here 
  sync :foo
end

[mrbombmusic]

There is an issue with this example which is if you listen, the :bd_haus only plays at the same time that the :foo note plays. As it is written, the :foo note is sleeping for 4 and the bass drum is sleeping for 1, so you should hear the bass drum play at the same time as the :foo note and then 3 more times before the :foo note plays again which doesn’t happen here because after it plays, it is waiting for the next cue sent by the :foo note which doesn’t happen until it sleeps for 4.

One way I have gotten all live_loops to come in at once is to send a cue :tick from my first loop and then put a sync :tick before all the following loops and that seems to work.

Here’s an example. I included 3 loops for this to show they will all come in together.

live_loop :foo do
  cue :tick #sends tick cue
  play :e3, release: 0.5
  sleep 4
end

sync :tick #syncs following loops with tick cue which starts at the beginning of first loop
live_loop :bar do
  sample :bd_haus
  sleep 1
end

live_loop :melody do
  play scale(:e4, :major_pentatonic).choose
  sleep 0.25
end

The problem with this is that if you try to change anything in your live loops, there will be a one tick delay before it happens which can throw everything off. So it is not ideal for live coding where I think @martin has a good solution with having a metronome loop to hold everything else together. But if you aren’t planning on changing anything and just want all your loops to start at the same time, this method should work.

[kniknoo]

I feel like maybe I’m missing part of your greater intent. In my own practice, to achieve what you’re doing I would not even be bringing sync in. If you manually time things, that is just remove the sync altogether, you’ll get the four kicks with the note on every first. There’s no risk of drift or anything like that.

However, here’s an example of how I frequently use sync.
https://gist.github.com/kniknoo/fef3f4738828f219c72c62ab03164793

[Martin]

 sync :drum if one_in(6)

@kniknoo: that’s an interesting use of the sync-commant. I will check this out …

@all: It all depends on where your preferences are, I think. My main concern is not, whether the code will start with a delay of one beat (refering to my example with :metro). I am more concerned about to be able to stop a loop, start it again and have it in sync with the others.

Here is an example on what I mean:

  # Marks the beats
  live_loop :beat do
    sample :elec_blip2, rate: 1, amp: 0.25
    sleep 1 # counts every beat
  end

  # Marks 4 bars
  live_loop :four_bars, sync: :beat do
    sample :elec_blip2, rate: 1.5, amp: 0.5
    sleep 16 # counts 4 bars
  end

  # Bass Line "Radio Musicola", Nik Kershaw
  bassline = (ring :b2,:b3,:e2,:e2,:r,:r,:e3,:g2,
              :r,:e2,:g3,:e2,:r,:g3,:e2,:g2,
              :r,:e3,:e2,:g3,:e2,:r,:g2,:r,
              :e2,:g3,:e2,:g2,:r,:d2,:e2,:g2,
              :a2,:r,:e2,:a2,:r,:e3,:a3,:a2,
              :gs2,:r,:r,:e2,:gs2,:gs3,:e2,:gs3,
              :r,:e2,:e3,:gs3,:e2,:r,:gs3,:e2,
              :gs2,:r,:e3,:gs2,:r,:e2,:a2,:as2)

  # bassline
  live_loop :bass_line, sync: :four_bars do
    stop # comment to start loop; should be in sync with :pad
    use_synth :fm
    use_synth_defaults amp: 1.0, attack: 0.0, attack_level: 1.5, sustain: 0.15, release: 0.05, cutoff: 70
    play_pattern_timed bassline, 0.25
  end

  # chords
  live_loop :pad, sync: :four_bars do
    stop # comment to start loop; should be in sync with :bass
    use_synth :fm
    use_synth_defaults amp: 0.25, attack: 0.1, sustain: 0.5, release: 3
    with_fx :echo, phase: 1.0, decay: 2 do
      with_fx :reverb, room: 0.75, mix: 0.75 do
        with_fx :flanger do
          with_transpose 12 do
            play [:b3, :b4, :d4, :fs4, :a4, :fs5]
            sleep 1.5
            play [:d3, :g4, :a4, :d4, :g5], release: 6
            sleep 6.5
            play [:a3, :e4, :a4, :b4, :e5]
            sleep 1.5
            play [:gs3, :gs4, :e4, :b4, :e5], release: 6
            sleep 6.5
          end
        end
      end
    end
  end

[kniknoo]

Oh! Ok, I’m with you now. I’ll have to think on how to answer your question directly. But in my own practice, I use comments as mutes a lot, it’s the majority of what I’m doing on stage. I comment out the play/sample command and then bring it back so it never leaves time. If I use stop, it’s when I’m done with a loop altogether, or if it’s really taxing and it needs to stop and I want it back, I’ll uncomment a sync when I comment the stop again.

[Martin]

I see… Yeah, that’s another option and I use this also.

Sometimes though I do not need to run all live_loops at the same time (I mean musically); additionally there are quite a few things going on perfomance-wise - then for me it’s a better solution to be able to save perfomance by being able to start/stop the loops.

(Oh, just looked up taxing (you mean taxing for the machine?). Maybe you are talking exactly about what I just wrote )