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.
The difference in performance won't be noticable, but both lookups and
modifications in these things are much faster once you have more than
one or two elements.
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.
The VST3 version of Voxengo TEOTE would deadlock in Ardour when Ardour
calls `IEditController::setState()`, the plugin calls
`IUnitHandler::notifyProgramListChange()` in response, and then when
Ardour calls `IUnitInfo::getProgramName()` while handling that callback.
All of these functions have to be called from the same thread in Voxengo
plugins.
Those DAWs would immediately call `IEditController::performEdit()` with
the same parameter change the plugin has just announced, which would
result in a deadlock. Hopefully this helps with #100.
This reverts commit a495f1a67f.
This ended up not being an issue. What we _do_ have to do, sadly, is to
have a mutual recursion context stack per plugin. Otherwise multiple
plugin instances can deadlock eachother.
FabFilter plugins will exchange messages that have to be handled from
the GUI thread, or they'll get stuck waiting on a synchronisation
object. This probably hurts GUI performance significantly but luckily it
only affects Ardour.
Instead of serializing the actual `YaMessage`, for the reasons mentioned
in the comments. This was needed to stop iZotope VocalSynth 2 in Ardour
from segfaulting when editing parameters, because that plugin is
apparently being very naughty.
I copied this from the SDK implementation and they don't do any pointer
casts there because it's not strictly necessary, but they're relying on
implementation details that may not always hold true.
It's not necessary, since all of these objects are simple data objects
that will be passed as arguments to other functions. When we have to
pass through one of those functions we can just serialize the objects at
that point.