VST3 plugins could freeze in REAPER when the plugin sends
`IComponentHandler::performEdit()` followed by
`IPlugFrame::resizeView()` when REAPER simultaneously tries to call
`*::getState()`. Here `*::getState()` gets called from the GUI thread,
while `IPlugFrame::resizeView()` has to be handled on REAPER's GUI
thread, resulting in a deadlock unless we use the plugin-side mutual
recursion mechanism.
I've seen this cause issues with PSPaudioware InfiniStrip.
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.
Apparently the destructor for C++17/20 conditional initializers are only
run after the else branch, so this would keep the mutex locked while
executing `do_call()`.
For individually hosted plugins this will behave the same. For plugin
groups it would have been nice if we could shut down individual plugins,
but dangling threads are apparently a real issue. This should be
equivalent in all use cases.
This also reverts commit bda9a0b75f.
We would never try to shut the group host down if nothing ever tried to
connect to it. This could happen when the native host gets killed after
initializing the yabridge plugin but before it gets the chance to
request the group host process to host a plugin.
This will let us more or less gracefully handle failing host callbacks
during initialization. We cannot catch this from anywhere else since
this these functions get called from unmanaged code.
This means we only have to compile everything two times, instead of four
times. We sadly still need to compile lots of files at least three
times. (once for native, once for 64-bit Wine, and once for 32-bit Wine)
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.
When setting the state on the audio processor, it can happen that plugin
triggers a resize from the edit controller. We should also be able to
handle that situation.
With this we should be able to handle `setState()`s that try to resize
the currently open editor. This could pop up when using the preset
browser in REAPER with plugins that recall their old size when loading a
preset.
At least for performance reasons, since with the changes in yabridge
3.2.0 they VST2 plugins perform as good or better depending on the
plugin groups settings. Using plugin groups is still less preferable
than using the VST3 version of course.
This greatly improves compatibility with VST3 plugins in Ardour and
Mixbus. Most notably the FabFilter plugins would previously freeze when
having the GUI open while duplicating or inserting new instances.
I haven't seen this cause any issues this way, and I could imagine that
this could cause some hangs when initializing a second instance of a
plugin while you're interacting with the GUI of the first instance.
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.
Robbert van der Helm