Also don't automatically flush the delayline at transport or monitor-
changes anymore.
With full-graph latency compensation, delaylines are before the
disk-reader, aligning input (disk uses read-ahead to align).
Flushing the delayline should only happen when input-monitoring
is disengaged. It's best degated to the Route or object using the
Delayline (potentially latency-aligned delayed flush).
This also tweaks fade behavior when the latency changes to prefer a
x-fade when possible.
This new variant does not support concurrent re-allocation and
execution. Hence the auto-connect thread needs to take a lock before
updating latencies (actually there's no need for an explicit update with
built-in backends, so this case remains to be updated further)
74c986534b changes the semantics of fader-flags:
NoVerticalScroll was "ignore vertical scroll for horizontal faders".
Now the flag ignores all vertical scrolling.
The processors will becomes responsible to know about loop-positions
and map latency-compensated start_sample, end_sample into the loop-range
as needed.
Previously Ardour used a /local/ per track vari-speed mechanism.
Now that the disk-reader is a latency-compensated processor, the speed
of each disk-reader would need to be maintained locally, offset by each
disk-reader's output latency. Furthermore each disk-reader may
produce a different number of samples, depending on its global alignment.
This commit introduces port-data resampling directly at the engine-level:
Up/down-sample all input ports at the beginning, and down/up-sample output
port-data using the inverse ratio at the end of the session's process
cycle.
The session itself is unaware of the speed-change, and only needs to
handle transport speeds {-1, 0, +1}.
This also allows for aligned cue-monitoring and vari-speed recording,
and also pitch-shifts synthesized MIDI along.
