Feature Request: Start at a specific time

[Cedware]

It would be very useful, if it would be possible to jump to a specific point of time, because it is very time intensive to listen some minutes if you just want to think about a specific part of a track

[samaaron]

Interesting idea. How would you imagine that this would work? For example - how would you specify to jump to a specific time?

[emlyn]

This would be very useful when working on a particular part of a longer composition.
I often end up copying and pasting parts to a separate buffer, tweaking them, then copying them back. But that can get quite fiddly, especially when there are different parts to keep in sync.

How about something like this:

time_travel 60 # jump 60 beats into the future
30.times do
  play :a
  sleep 2
end
play :b

This would make Sonic Pi skip over sleeps for the next 60 beats (in the code above), also ignoring play/sample etc, so it would only play the :b and then stop.

[rbnpi]

This is interesting. I often find it a problem in the long pieces I write. If I have tempo changes I often bypass one section by setting the tempo very high e.g. 600 or 800 Bon and the reducing to normal again. Some system to jump a number of beats very fast would be great

[Cedware]

@emlyn
This is the way I would like to use it by maybe by time in second instead of beats

[emlyn]

Yes, thinking about it, it probably only makes sense to specify time in seconds. You may well have two or more threads at different BPM, and you want them all to start at the same time.

[samaaron]

I've put some thought into this and have a rough idea of how to do it. However, I have a couple of problems that still need solving:

• What happens if whilst moving through time, the program reaches a call to sync? Should this result in an error?
• Once we have official support for OSC and MIDI output - should jumping through time skip sending these messages? What if they are required to set something external up?
• Should we treat FX synths differently from calls to play? It seems to me that we should still be firing off the FX in the background in case we jump into the middle of a with_fx block and expect the FX synth to be running in the background when we actually play the next synth.

[emlyn]

• Is there a problem with continuing to process sync/cue while moving through time? So a sync would stop at that point until some other thread sends a cue (and then inherit the time of the sending thread?), and if none do, then it will still be waiting when playing starts again.

• My instinct says that external OSC/MIDI should also be skipped. Any necessary setup could be done before the call to time_travel (or whatever it ends up being called). But maybe there could be some way to override default behaviour for edge cases like this? (something like a with_xxx, enable_osc: true do ... block, obviously not called xxx but I can't think of a name right now)

• I agree that FX should probably be treated differently. But maybe as an optimisation you could keep track of which ones were started without actually firing them off, and then only actually start them if they are still active at the end?