The sizes were wrong, and Blue Cat Audio's VST3 plugins seem to use the
upper bits to store the channel configuration, which thus got read out
incorrectly.
In the same way as 50c25c1cf0 did it for
VST2 plugins. Input and output audio data is now stored in a shared
memory buffer instead of being sent over the sockets. This reduces the
bridging overhead to a minimum since copying data was the most expensive
operation we were doing and we now only need to copy the entire buffer
once per processing cycle.
We now use shared memory to store the input and output audio buffers.
This means that we have to copy less data every processing cycle, since
a single copy to and a single copy from the shared memory object
suffices now. This should reduce the DSP load for VST2
plugins (especially when used in a plugin group) marginally to
significantly depending on the plugins used and the system
configuration.
Bundle all serialization function with the structs whenever possible to
simplify the serialization function, and add `Foo::Response` types so we
can make the `passthrough_event()` function slightly more type safe.
This could prevent resizeable plugins from being resizeable in Ardour if
the initialized timestamp just happened to be greater than the current
time, since the returned result would then likely be some invalid value.
String constants will be converted to `std::string` because it's not
constexpr yet, and that will allocate for longer strings. Since this
function only prints something when `YABRIDGE_DEBUG_LEVEL` is set to 2
or higher that seems like a waste.
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.
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.
Robbert van der Helm