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
