When locating while writing automation, begin a new write-pass,
and add a guard point at the locate target position.
NB set_in_write_pass takes 3 arguments: (write_enable, add_point, when)
the last two default to false, 0.
103ef2ba08 introduced an API to write raw data (const void*)
to a child process, along with the previous API to
write (std::string const&)
VideoMonitor uses write_to_stdin("fixed text"), and g++
interprets this to use the (const void*) API instead
of the std::string, which breaks communication.
Pre-roll to fill buffers only needs to be done once when starting
to play or when locating.
Seamless looping just continues. Every processor takes the loop
position into account locally.
We never stopped the transport, so there's no reason to start it again. Doing so causes alignment problems
because all tracks have their ::run() ranges reinitialized
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
Although at the Session level we never run "through" the loop end,
latency compensation means that that start/end sample values passed to
Processor::run() may cross the loop end. Fix how we handle this so
that we do not read data from after the end of the loop
Split cycles are run as if they are an entire self-contained cycle, starting at zero and running for "nframes".
We adjust the timing and position of data only when retrieving and writing it to Port buffers.
All _immediate_events data gets written to the output buffer at the end of the current (split) cycle anyway, so the
timestamp is irrelevant (as long as it is zero, and will therefore be read by ::snapshot_out_of_band_data()
