In commit 9788f21e0e we changed the input
focus grabbing to only grab focus once per event cycle, because
otherwise Bitwig would fight over who was getting focus. This is a bit
hacky, and with this approach you could in theory still have an
unnecessary focus grab 60 times per second (i.e. the default event
polling rate). Now we instead check the current focus target, and only
request focus when it's actually necessary.
It sort of goes against yabridge's principles to not do these
unnecessary `audioMasterGetTime()` calls if the plugin does that, but it
also hurts the user experience to not have this as a default.
This works around an issue with REAPER. During every processing cycle
REAPER would query how many input and output busses we have, and it
would then enumerate over all of those busses. This meant that if a VST3
plugin has 32 output busses, then REAPER will do 34 extra function calls
before processing audio.
We didn't initialize the field, and we also didn't copy the updated
value back (since everything else is a pointer to the original data).
This fixes audio channels in REAPER randomly being silence, as this
field would otherwise be uninitialized.
Thanks a lot to @kytdkut for finding this issue!
Ever since 0bed2b7bc0 REAPER will randomly
not play back one or more audio channels for plugins that support
IPlugViewContentScaleSuport. If you return `kNotImplemented` then this
bug doesn't occur. REAPER should definitely fix this soon. With
`kResultFalse` this issue still occurs, hence this change so you can use
`vst3_no_scale` to work around this REAPER bug.
I haven't seen this cause issues myself, but it would not surprise me if
a plugin that produces a constant stream of FIXMEs would steal resources
from audio processing if the threads that are relaying those messages
are set to SCHED_FIFO.
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.
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.
As pointed out on the Discord. Fixing this will require a breaking
change, but right we report incorrect plugin IDs meaning that projects
saved under Windows cannot be opened under Linux with yabridge so this
really needs a fix.
This still seemed to work, but the `sched_setscheduler` would return an
error code when the priority is set to 5 for SCHED_OTHER (which is of
course not a valid value here).
It's pretty hard to find a solution that checks all of the boxes. I want
something that:
- Closes instantly when you close the editor, and in REAPER you should
be able to instantly switch between docked and floating modes
- Where there should not be a delay in user interaction when quickly
reopening the editor (or doing that switching thing in REAPER since that's
the same thing)
- Where the window manager should not try to reparent the window during
the losing process as that can cause some jarring flickering
- And, of course, there should be no weird Wine X11Drv crashes
And it should do all of that in Bitwig, REAPER, Carla, Ardour and
Renoise. Apparently it's quite the task to find an approach that checks
all the boxes there.
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.
Robbert van der Helm