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
In many cases optional sidechain inputs are not used.
Previously sidechain ports were created, but remained
unconnected and silence was passed to the plugin's key input.
Plugins can detected if a pin is connected. Some plugins
(e.g. VST3 Waves SSL Comp) activate the sidechain processing
automatically when depending in connection.
It is more common that a user does not want to use an external
sidechain, and if they want they should use the pin-dialog
to connect it. So leaving it off by default is sensible.
see also #9223
This is in preparation to allow to skip adding sidechain ports
by default. When a user later adds the SC input ports, it is
convenient to connect the pins just like they are when they
are connected when instantiating the plugin (via reset_map).
Ignore sidechain pins, when no sidechain ports are present.
Otherwise a plugin with 1 audio input and 1 sidechain input
would match a stereo track when the sidechain port is not present.
These tests use reference files that were generated with a particular
value for superclock_ticks_per_second. The default for that has changed
since the last time the reference files were updated though, causing
tests to fail. Rather than updating the reference files for the new
default value, this makes the test not depend on the default value by
hardcoding the value that was used to generate the reference files.
Only glibc has __ppc_get_timebase() function. On FreeBSD use the same assembly call that __ppc_get_timebase() actually executes.
This probably should be extended to musl and OpenBSD, but I have no way of checking that.
