This is needed as a workaround to support Waves VST3 plugins.
Right now does does not actually fix the issue because the arguments are
not updated in the subclasses. The next commit will fix this.
We sadly cannot call `shared_library()` and `executable()` in these
subdirectories while still maintaining the same `build/` directory
structure, but this is still much cleaner. All of the other build
artifacts are now also gone from the root of `build/` so it's cleaner
overall.
At some point Doom Emacs broke on-save formatting with lsp-mode in
certain circumstances, and I made these changes with wgrep so apparently
they were never formatted.
These only show up during unity builds, and they originate from
Boost.Container's small vector. The compiler's diagnostic also doesn't
make any sense here so it's probably just a weird GCC thing.
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.
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.
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.
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.
Apparently this can actually make a difference in some cases, and the
C++ Core Guideliens recommend doing this on all default constructors,
destructors, and all functions that can not throw (and thus also don't
allocate).
This is very ugly so hopefully I can think of a neater way, but now the
response object is just a set of pointers, so we can avoid all copies
and moves on the Wine side.
We do this by using this new `MessageReference<T>` type to avoid copying
our `YaAudioProcessor::Process` struct and the contained `YaProcessData`
object. This is only part of the work, but this redesign lets us keep
the these objects alive on both the plugin and the host side. On the
plugin side, we'll simply serialize the data from the referred to object
without copying it. On the Wine side, we'll write the data to a
persistent thread local object, and then reassign the
`MessageReference<T>` to point to that object. This lets us serialize
'references', thus avoiding potentially expensive allocations. With
these last few changes alone VST3 plugins are already at the same
performance level as our optimized VST2 plugin groups.
Bitwig prepends some data when passing an `IBStream*` to the plugin, and
when we do copy it iZotope Rx7 plugins cannot load their state (even if
we also copy over the same seek position). Not copying that preamble
fixes the issue, and it seems like it doesn't break anything.
This is embarrassing. Because the bus index was not being serialized,
all lookups were done for the bus with index 0. This meant that
sidechaining in Renoise didn't work because Renoise only allows
sidechaining to `kAux` busses and the first bus is always marked as
`kMain`. This would also cause Ardour to crash or freeze more often then
it should because while it does not support arbitrary bus I/O
configurations, it does support plugins with both a `kMain` and a `kAux`
input bus but since we would never get `kAux` busses Ardour just didn't
pass any buffers for the sidechain input.
`std::char_traits<wchar_t>::length()` would return the wrong length for
a wide string under Wine, and thus also for `String128`. This would
cause parts of the strings to get cut off. As a workaround we'll just
serialize the entire container including all null bytes at the end.
We didn't initialize the field, and we also didn't copy the updated
value back (since everything else is a pointer to the original data).
This fixes audio channels in REAPER randomly being silence, as this
field would otherwise be uninitialized.
Thanks a lot to @kytdkut for finding this issue!
Robbert van der Helm