find_next_ac_event, needs to find the next event *after* (but not
at) start.
std::upper_bound returns an iterator pointing to the first element
in the range [first, last) that is greater than value.
This is equivalent to using std::lower_bound an iterating until
finding the first element greater than.
Ardour 6 internally always runs at speed 1.0 (or -1.0, or stopped 0.0).
There is no vari-speed that scale "BPM" or "n_sample" time progression
per cycle.
Instead Ardour 6 vari-speed mechanism transparently re-samples I/O.
So process-time is scaled only relative to wall-clock time.
From a plugin's POV this is similar to "freewheeling": The plugin
processes data as if the host plays at speed 1.0. While the host
plays this data at a different rate.
Some plugins may like to be informed about the host's actual
playback rate.
Currently this is mainly for the benefit of github.com/x42/repitch.lv2.git
Previously setting a boolean-control to "write" and roll did not
create an automation-point.
The state was not correctly captured.
The boolean-control needed to be toggled explicitly to create
an automation point.
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()
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
