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()
This fixes an issue with existing MIDI routing between MIDI tracks
and/or busses. Automatic MIDI connections should only dis/re-connect
ports that are explicitly configured in Preferences > MIDI Ports
and leave all other connections alone.
This is made possible by knowing that it is never called upon to read across
loop boundaries. The session splits the process cycle for the end of the loop
