New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

live_loop syncing issue? #1730

Closed
ethancrawford opened this Issue Sep 18, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@ethancrawford
Copy link
Contributor

ethancrawford commented Sep 18, 2017

(Hopefully I haven't somehow completely missed this being reported already, and also hopefully I'm not just noticing expected behaviour!) - I have noticed that the following simple code example behaves differently between several versions of Sonic Pi:

live_loop :a do
  sleep 4
end

live_loop :b, sync: :a do
  sample :bd_808
  sleep 1
end

On v2.10 on my Mac, you can hear the bass drum sample start straight away.
On v3.0.1, both on my Mac and on Windows, (which are at different commits, but both say 3.0.1) the bass drum is not heard until after the delay of the first live loop's sleep.

@rbnpi

This comment has been minimized.

Copy link
Contributor

rbnpi commented Sep 21, 2017

I've been looking at this, and it does seem to be an issue. if you use auto_sync: it works

live_loop :a do
  sleep 4
end

live_loop :b, auto_sync: :a do 
  sample :bd_808
  sleep 1
end

Actually I think this is just fortuitous and is NOT syncing at all. the auto_sync will be ignored as an unkown parameter and the loop just starts anyway,

@mbutz

This comment has been minimized.

Copy link
Contributor

mbutz commented Sep 21, 2017

I can confirm this behaviour for SP 3.0 on Linux (Mint 18.1). And I also wonder, if this is an expectable behaviour:

live_loop :bar do
   sample :elec_blip2, amp: 0.5
   sleep 4
end
live_loop :test1, sync: :bar do
   play :c4
   sleep 1
end
live_loop :test2 do
   sync :bar
   4.times do
     play :g4
     sleep 1
   end
end
  • live_loop :test1 starts to sync when :bar has run once. (I might be wrong but I remember it to start imediatelly in SP 2.x)
  • live_loop :test2 also starts after :bar has run once. As far as I understood it should sync every time :bar runs. Every second :bar-run it stops. (Which is somehow logical given the behaviour of :test1.)
@ethancrawford

This comment has been minimized.

Copy link
Contributor Author

ethancrawford commented Sep 23, 2017

@samaaron I don't suppose this has anything to do with it but I also found some unused functions in event_history.rb

@ethancrawford

This comment has been minimized.

Copy link
Contributor Author

ethancrawford commented Sep 23, 2017

I don't know for sure but I wonder whether it's at least something to do with the event history class, (perhaps the wait_for_threads function...)

@samaaron

This comment has been minimized.

Copy link
Owner

samaaron commented Dec 20, 2017

This behaviour prior to v3 was non-deterministic (although it largely did the same thing). This is because the original implementation was a race condition with respect to cue/sync ordering.

In v3 I made this deterministic which also meant deciding on a repeatable set of semantics. This in turn means that each cue is totally ordered across all runs and all syncs are also ordered. In v3 syncs will only catch cues after them. Which means that for threads syncing and queueing on the same logical time, their thread ID will determine whether they are before or after.

In this case the live_loop is executing in a different thread to the main thread which is initiating the :sync and the ordering drops the first cue because it is not after it in the total ordering of events.

@mbutz

This comment has been minimized.

Copy link
Contributor

mbutz commented Dec 20, 2017

Ok. Thanks for clearing that up.

@ethancrawford

This comment has been minimized.

Copy link
Contributor Author

ethancrawford commented Dec 20, 2017

Cheers @samaaron. I'll close this as expected behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment