AudioPort::get_audio_buffer() can offset the buffer simply by offsetting
a pointer. This allows to get an offset buffer for a given port.
For MIDI there's no such concept. A method writing to a MIDI buffer
which is backed by a Port can at best offset it by the global port-buffer
offset (static Port::port_offset), but not by the individual target port's
offset.
This allows to push latency upstream and delay the source
in case the destination has a longer latency.
Also add a signal to notify the Session in case this happens, intended
to queue a latency-recompute.
The general goal is to align transport-sample to be the audible frame
and use that as "anchor" for all processing.
transport_sample cannot become negative (00:00:00:00 is the first audible
frame).
Internally transport pre-rolls (read-ahead) before the transport starts
to move. This allows inputs and disk to prefill the pipeline.
When starting to roll, the session counts down a global "remaning preroll"
counter, which is the worst-latency from in-to-out.
Each route in turn will start processing at its own output-latency.
Route::process_output_buffers() - which does the actual processing
incl disk i/o - begins by offsetting the "current sample" by the
route's process-latency and decrements the offset for each latent
processor. At the end of the function the output will be aligned
and match transport-sample - downstream-playback-latency (if any).
PS. This commit is a first step only: transport looping & vari-speed have
not yet been implemented/updated.
This is mostly to see if there'll be any problems when merging these changes into Mixbus. I'm guessing there'll be some conflicts in these projects (and a lot more to follow...)
After over 17 years of honorable service to the Ardour Codebase.
ClickBox and AutoSpin are retiring into the git nirvana.
We're glad for the duty, decency, reliability, dignity, respect which
these classes brought to Arodur and look back in gratitude on their years
of service.
PS. First one to say "cruft" will be fired.
Currently, the scroll handler obeys to the page increment, but instead
of using the step increment for more precise scroll, it uses an
hardcoded one tenth of the page increment.
Use the step increment instead since it has been filled with sensible
values by ArdourFader's users.
smallstep (resp. largestep) is intended to be the interface delta
corresponding to a desc.smallstep (resp. largestep) in internal scale,
and is computed by incrementing from desc.lower.
But ac->internal_to_interface(desc.lower) isn't necessarily zero. In
fact it currently is 0.5 / (M - m + 1) for integer parameters where M is
the maximum and m is the minimum possible value since it is the center
of the [0,1/(M-m+1)] interval.
Since the lower bound of the delta isn't always zero, don't ignore it
when computing the actual increment.
