When yabridgectl sets up both a VST3 bundle containing both a 32-bit and
a 64-bit plugin. The libyabridge.so file already existed, so the
reported number was always off.
Apparently you can tell udisks2 which options are safe to be used by a
user. More recent versions of udisks2 include the udf unhide option by
default. This closes#102.
While a VST2 plugin is being initialized in a plugin group, all host
callbacks would go over that new plugin instance's sockets. This would
cause a race condition if the host processes audio while loading
plugins. This issue has been there since the introduction of plugin
groups, but it's only noticeable in Bitwig Studio, and only when using
over thirty instances of the same plugin in a plugin group.
Should be equivalent. The only reason why we use container2b in some
places is because strings based on `Steinberg::char16` arrays will have
an incorrect length on the Wine side, because character traits for
`wchar_t` is still reflects Linux instead of Windows there.
PG-8X in REAPER has the same mutual recursion limitation the Voxengo
plugins had in Renoise, but with `effGetProgramName()` instead of
`effGetProgram()`.
This basically changes the default small vectors during VST2 event
processing from 256 bytes to the size of a `DynamicVstEvents`
object (which also includes a small_vector to hold MIDI events without
allocating) and makes them thread local. We already have a similar
optimization for VST3. There it's a bit neater since we already had to
separate audio processing functions from non-time critical functions.
Here we don't have that separation, so we just made these buffers thread
local, large enough to hold our predefined number of events, and we then
just shrink them to fit if these buffers grow even more (which can only
happen after reading or writing chunk data).
The change doesn't specifically target `effProcessEvents()`, but that's
where you would see the differences. This is also relevant for
`audioMasterProcessEvents()`.
Apparently we also never did this for VST2 plugins, so this should be
safe. Filling the vectors with zeroes here had a non-negligible
performance impact according to perf.
I once read years ago somewhere on Stack Overflow that `std::vectors`
with that are preinitialized to a default size would allocate the
initial capacity on the stack. This of course doesn't make any
sense (run time sized stack allocations can cause all kinds of issues),
so we were still allocating with our default 64-byte sized buffers, but
just not as often.
C++ would always construct an `std::string` from the string constant
every iteration. Since this also happened when `YABRIDGE_DEBUG_LEVEL` is
not set to 2, this ended up causing unnecessary allocations.
Events, parameter changes, and the individual queues contained within
the parameter changes all use dynamic memory allocation. Preallocating
some memory for those things inside of the objects may prevent latency
spikes when they those objects are first filled. This is especially
useful for the parameter changes since there's no way to reserve memory
in a vector of vectors.
This prevents reinitializing `std::variant`s when the variant we want to
deserialize is already active. We store audio buffers in variants, so
reinitializing them results in a lot of unnecessary memory frees,
allocations and writes during every processing cycle.
I blindly assumed the original implementation also did this, but this
version `std::variant<Ts...>` objects from being reinitialized if we're
deserializing a variant that's also currently active in the object we're
deserializing into. For simple structs this won't make any difference,
but in yabridge we often use variants to differentiate between things
like single precision and double precision audio buffers. Those buffers
are allocated on the heap, so recreating the objects every time we
deserialize them adds a lot of unnecessary overhead.
We did a ton of work earlier to make sure we can reuse these objects,
but `auto` implies the type is never a reference type, and we were thus
unnecessarily creating copies every iteration, kind of defeating the
purpose of doing all of this in the first place. We could do some
template trickery here, but it's also safe to just make the persistent
object thread local since the actual objects aren't that large.
We don't need any special handling for this since our default argument
detection will handle strings, but it might be useful for log output if
a host ever uses this. At the moment there don't seem to be any hosts on
Linux that use this.
Robbert van der Helm