This avoids doing the duplicate check (since both `setProcessing()` and
`setActive()` would be called), and this also gets rid of the assumption
added a couple commits ago that `setupProcessing()` is only ever called
once, which is not true.
This wasn't implemented yet because no plugin tried using the interface
in this way before this, but Surge XT incorporates the host's context
menu items into their own (much more elaborate) context menu. To
accommodate this, we now copy over all of the host's prepopulated
context menu items to the Wine plugin host, and calling the targets
associated with any of those items will cause the target on the
associated context menu item on the host to be called.
This is slightly more complicated than what would otherwise be necessary
because Bitwig does not assign tags to their context menu items and
instead always uses 0.
I'm not a fan of Hungarian notation, but C++ kind of needs it with its
implicit `this`. And of all the common options for this, I find
suffixing members with an underscore the least offensive one.
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.
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.
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.
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.
I was wondering why I couldn't find the overload for `UniversalTResult`,
and as it turns out we would always use this variant (which
unsurprisingly was the very first overload added). We should of course
have separate overloads for this.
This is in some cases needed to get decent performance in REAPER, as
REAPER seems to query this information (which cannot change without the
plugin requesting a restart) four times per second.
Robbert van der Helm