This is a bit of a mess (which is also why I kept procrastinating on
this), since we also need to keep symlinks, trailing slashes, and weird
unnormalized paths into account.
This should not be causing any issues, but it seems like some people
skip the locale setup step in the Arch installation guide and then end
up with a distro without any locales, with invalid locales, or with a
non-generated locale. glibc and libstd++ fall back to the C locale when
this happens, but Boost.Process triggers one of the edge cases where
this doesn't happen. https://github.com/boostorg/process/pull/179 fixes
this in Boost.Process, but it will be a while until this is in every
distro's copy of Boost.
https://svn.boost.org/trac10/changeset/72855
We apparently didn't do that yet. SysEx should be super rare (outside of
octave switching on Arturia keyboards), but there's still no reason not
to do it.
This was the original idea. I though that to be extra safe, maybe we can
do this all the time. And while that does work fine, most of the time,
it does cause a lot of other fun issues especially when plugins fully
redraw themselves that way.
The goal is to have the window be at (0, 0), while Wine's X11 event
layer thinks it is at the actual screen coordinates. This is needed to
prevent drawing issues with buggy plugins that rely on absolute screen
coordinates to draw their GUI.
We accidentally reverted a little bit too much code in
762e622416. This didn't appear any sooner
because plugins are supposed to call `IPlugFrame::resizeView()` during
`IPlugView::attached()`, so this only affects plugins that don't confirm
to the spec.
This reverts commit ff76e482f2.
This was a workaround for a race condition in Nimble Kick when opening
the editor while the plugin has not yet been authorized (a Win32 timer
proc between `IEditController::createView()` and `IPlugView::attached()`
would cause a stack overflow because the plugin doesn't check if the
things it wants to use have actually been initialized yet).
But as it turns out, Bitwig Studio now calls
`IEditController::createView()` unconditionally when loading a VST3
plugin, regardless of whether the user wants to open the editor or not.
So this workaround would cause the message loop to be stalled
indefinitely until you open the editor. Since this would also cause
Nimble Kick to break in the Windows version of Bitwig, we'll simply
revert this workaround. If you need to activate the plugin on Linux, you
can load it in the Windows version of REAPER running under Wine instead.
After that the plugin will work just fine under yabridge.
Instead of ignoring all `NonlinearVirtual` events. This lets us release
focus when instantly moving the mouse from a plugin GUI to something
else. This generates `NonlinearVirtual` event, and previously we ignored
those because that also happens when opening a dropdown menu in a TDR
plugin (which uses popup windows instead of actual dropdowns).
This should in theory prevent Nimble Kick from triggering a stack
overflow when the event loop timer procs before `IPlugView::attached()`
gets called and the plugin hasn't been registered yet. I haven't seen
any other VST3 plugins trigger a race condition here.
I've seen this happen once or twice. Earlier on (in #40) we could get
away with just reparenting the window another time. But here both
reparents succeed, and the issue still happens. But a reparent notify
for `parent_window` did appear on system affected by this issue, which
is very odd. Hopefully this will help.
Robbert van der Helm