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.
Now that we can require glibc 2.3.4, we can use RTLD_DEEPBIND.
This can help with plugins that do no hide symbols for their
contained statically linked libraries, and instead would use
use symbols.
Note: This only works on Linux.
CPUID is part of x86_64 ISA to query CPU features. In order to determine
AVX512F ISA extension, EAX and ECX needs to be set to 7 and 0
respectively before invoking `cpuid` instruction. This commit also
removes inline assembly for __cpuid in favor of using compiler provided
intrinsic functions. Both GCC and clang provides __cpuid like function
via __cpuid_count intrinsic.
This commit also creates a portable wrapper over compiler intrinsic
functions, __cpuid and __cpuidex. `cpuid' provides base level ISA query
and `cpuidex` provides extra extension information like AVX512F. These
wrappers lean towards MSVC like API.
References:
CPUID Docs: https://en.wikipedia.org/wiki/CPUID
GCC's ``docs" on __cpuid_count:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/cpuid.h
Clang's docs on __cpuid_count:
https://clang.llvm.org/doxygen/cpuid_8h.html
MSVC's docs on __cpuid and __cpuidex:
https://learn.microsoft.com/en-us/cpp/intrinsics/cpuid-cpuidex