Setting up VST3 plugins without yabridgectl is a lot of work and quite
error prone, so it seems like a good idea to now modify the CI build
artifacts to merge the yabridgectl binary in with the regular archives.
Those also resolves#67.
If `yabridge-host.exe` were somehow to be run with a socket base
directory that's not inside of `$XDG_RUNTIME_DIR`/`/tmp`, then we'll now
warn instead of removing that directory. This should not be necessary,
but in case someone wants to write a wrapper around
`yabridge-host.exe.so` us using a custom `$WINELOADER` then this could
save a lot of headaches.
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.
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.
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 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.
GUI drawing should not be able to interrupt the cores that are handling
DSP, but it seems like that was happening for some people with
suboptimal kernel configurations. This will require some more extensive
testing to see if these changes don't actually increase DSP load.
This fixes EZdrummer not producing any sound, as the plugin presumably
schedules some task on the Win32 message loop to load its resources,
which won't happen if this is run from any other thread.
Although it hasn't shown up, this will get rid of the possibility of
off-thread effEditIdle calls causing issues. And since we need some way
to run call this function while the event loop is running anyways, doing
it entirely from a timer similar to how hosts on Windows would do it
seems like the best solution.
While this does get rid of artifacts, it can also add a brief moment
where the gray background becomes visible when the window reconfigures
which can look jarring.
This reverts commit 35c7138333.
But do suggest enabling them in the readme and enable them on the CI.
Having them enabled by default breaks clangd/ccls, which doesn't sound
like a great idea.
https://github.com/mesonbuild/meson/issues/8146
I've also tried a lot of other things, but none of the solutions I've
tried work 100% of the time. It sounds like a better idea to have
something that doesn't work consistently than to have something that
inconsistently sort of works. Setting the size in `WM_WINDOWPOSCHANGING`
to (0, 0) fixes the drifting, but the mouse coordinates are still wrong
and `SetWindowPos()` breaks the reparenting.
This reverts commit db2cc5800a.
I think some rounding in Wine is causing this issue, but then again
we're not supposed to send these ConfigureNotify events to the window
directly anyways.
Robbert van der Helm