This code presumably intended to name sources "foo%a", "foo%b" etc, but
since it was incorrectly appending the character as an integer sources
instead ended up being named "foo%97", "foo%98" etc.
Also changes the branching logic to use this branch upto 26 channels,
rather than just upto 25 channels, as that seems to have been the
intention.
This is relevant when bouncing track -> track -> n/c.
It also helps to balance send latency route [send to bus] -> n/c
when the bus is connected to master or outputs.
This undoes edd68d8682, "ExistingMaterial" worked IFF
the click playback was exactly 1 cycle delayed and the
disk-writer _playback_offset was set to 1 cycle.
Now that audio buffers are flushed (see prev commit), the
click I/O's output is directly available and CaptureTime
is the correct alignment (as it always was).
Forward data for ports that are both internally and
externally connected.
e.g. click-io may be connected to a track as well as physical
outputs. Since the port is externally connected, data is written
to an internal buffer _data[], and only at cycle-end resampled
to engine-buffers.
However a track's recording the metronome is not externally
connected. Hence data is directly read from the engine-buffers.
Summing also happens at engine level, so data has to
be written back for downstream ports to read them in the same cycle.
* Fix reset on timeout: Reset needs to be called before
processing any messages.
* use DLL to compute BPM (remove 1st order LPF)
* set BPM before calculating ppqn
* Fix speed at 1.0, change BPM only. MIDI clock must
vari-speed (which changes pitch). MIDI clock is acts as
"Conductor" that specifies when a beat happens at a given
wall-clock time. timecode moves at speed 1.0 only the BPM
changes.
* Honor MCLk stop messages, do not auto-start as soon as
the tempo is locked (after 3 clock ticks).
* Retain MIDI beat position, do not rewind in ::update_midi_clock
Do not directly start when receiving the position message,
transport speed should be zero (regardless of clock speed),
until the "continue" message arrives.
* Mclk start needs to rewind (not reset)
There is still an issue with start, when
_session->transport_sample() is not zero. Ardour ends up
constantly locating, rolling for a short time and re-syncing
by locating again.
For normal cairo-widgets ardour should not use image surfaces on macOS,
because that bypasses retina scaling. In theory explicit upsampling could
be performed (compere to openGL/cairo), but for the case at hand that is
overkill and inconvenient.
Performance critical widgets that render periodically can enable openGL
backing. Casual widgets (buttons with text, knobs, sliders etc) can be
rendered directly without any significant performance penalty.
Some plugins call back to restartComponent() directly from
IEditController::setComponentState.
This lead to a deadlock since VST3Plugin::load_preset
takes a lock (since 7.2-85 b27467157b), and restartComponent
takes the same mutex again.
This fixes an issue with Blendeq (and likely other plugins)
that call `restartComponent(Vst::kLatencyChanged) from the
in realtime context from plugin's process
e.g. loading a u-he zebra preset using the plugin's GUI
internally changes the controller state without using the
`performEdit` API, but instead calls `restartComponent` wit
the `kParamValuesChanged` flag to perform a a batch update.
This now also updates Ardour's AutomationControl to match.