We'll periodically copy the scheduling priorities from the host's audio
threads to the Wine plugin host's audio threads. The overhead of doing
this is about 1 microsecond on my system, so doing this every cycle
really adds up. But getting the Unix epoch time and comparing some
timestamps has a neglegible overhead, so this should give you the best
of both worlds.
Next we'll do the same thing for VST3 plugins.
As suggested by @jhernberg
This is a breaking change. Old projects containing VST3 plugins running
through yabridge will no longer work without modifications. I'll write
some scripts to convert the class IDs stored in those project files soon
a migration path.
The UIDs reported by the plugin were apparently wrong, which meant that
the native Linux VST3 version of plugin X and the normal Windows VST3
version of plugin X used different class ideas than the Windows VST3
version of plugin X running through yabridge. Those things are supposed
to be compatible, so we sadly needed to make this change at some point.
This got removed in 74dc8225d1 when I
wanted to rework all `*Impl` classes the same way I did with
`YaPluginFactoryImpl`. This ended up not being possible, but
accidentally also removed this forward declaration. With unity builds
this did not cause issues however, but with regular builds it might
depending on which files are changed.
This prevents REAPER from crashing when removing the last instance of a
plugin and then readding it. REAPER doesn't unload the module even after
it removes its last plugin factory instance. This means that before this
the plugin factory would be freed but we still had a seemingly valid
pointer to it that we would try to access.
By directly stopping the IO context there was a chance that a task would
get cancelled outright if all stars aligned in the wrong way. Stopping
the IO context could happen between posting the task to the context and
waiting for it. This approach is much safer as we cannot drop any work
this way.
This would cause crashes in Bitwig, as `RunLoopTasks`' destructor would
not be run after the event handler has been unregistered, and we
unregister the event handler in that destructor.
I've never seen this happen, but now this too would support deeply
nested mutual recursion just like we implemented in
`Vst3PlugViewProxyImpl`. Better safe than sorry.
This was a bit of a tricky one because it requires simulating mutual
recursion, but it's needed for REAPER as otherwide calls to
`IPlugFrame::resizeView()` and `IContextMenu::popup()` might cause
REAPER to segfault because its GUI is not thread safe.
This also changes the refresh rate for most plugins. You can now lower
this setting if your computer is struggling to keep up with rendering a
certain heavy plugin.
Robbert van der Helm