This was a nasty race condition that only seemed to pop up with Spitfire
plugins in REAPER, but it could also happen elsewhere. The
`active_plugins_mutex` was getting locked from the message loop, but the
plugin would block until `effOpen()` had been called. But because the
mutex was locked by the message loop we would never get to handling
`effOpen()`. Passing the pointer directly both removes this unnecessary
locking and fixes the issue.
When the message loop is active and we get an incoming dispatch() event,
we'll just handle it directly. In practice this would only be needed
when the event is a response to an `audioMaster()` call made during the
event loop, but we can't know that. This allows the `getProgram()`
during `audioMasterUpdateDisplay()` in REAPER and Renoise to work
correctly. Hopefully this doesn't cause random rare breakage.
This cleans up the PluginBridge significantly by getting rid of all
fields and handling that was only needed for connecting to plugin
groups. This was also the last thing I wanted to refactor before
releasing the plugin groups feature with yabridge 1.2.
Running the audio processing and midi dispatcher loops in a regular
`std::thread` causes weird memory corruption issues (likely because of
calling conventions are not being respected). Luckily this does not
cause any issues here, so we can get rid of a lot of ugly glue code and
manual memory management.
This makes the individual plugin host slightly more complex, but now
both individually hosted plugins and plugin groups handle both
dispatcher events and GUI events in the exact same way.
At a 30 fps rate with a limit on the number of window messages per
frame. This is somehow needed for Melda plugins, as they otherwise
dispatch tiemr messages indefinitely after opening a second editor with
seemingly no way around it.
With this and some refactoring #15 should be almost done.
This is a bit more restrictive than the old approach that only skipped
when `effEditOpen()` got called after `effEditGetRect()`. Not sure why
the Melda plugins block indefinitely on the message loop without this
now.
This allows for a significant speedup in plugin scanning time for plugin
groups, since starting Wine processes takes up pretty much the entirety
of the time spent scanning plugins.
Robbert van der Helm