As reported in #149, the DrumCore 3 plugin would segfault when trying to
drag files from it. This happened because the plugin presumably
underflows somewhere and then reports that it supports 4294967282
different drag-and-drop formats, even though yabridge asked for a
maximum of 16.
They aggressively use the message loop when parts of a plugin's UI
change, sometimes sending as many is 2300 events at once. The old 20
messages per tick limit would cause severe slowdowns in this case.
Since this was never stopped, the `watchdog_handler` thread would also
keep running. Since after e3f0926aef
everything is supposed to exit cleanly, this would cause group host
processes to hang and never exit. Tying the watchdog timer to
`MainContext::run()` is cleaner anyways.
This check was only needed because `operator[]` inserts an empty entry
if the variable doesn't exist. Wine also complains when `WINEPREFIX` is
empty, so we should probably not try to have our own behavior here.
...before terminating it forcefully. Not sure why this
`TerminateProcess()` was here instead of in `group-host.cpp` in the
first place. This way we don't have to duplicate any destructor
behaviour.
This would be useful if you need to do some elaborate namespacing setup
and want all sockets and other temporary files in a single directory
instead of in `${XDG_RUNTIME_DIR:/tmp}`.
This resolves#139.
Apparently these arguments are all passed as a space separated Win32
command line, so we need to do our own quoting. I was about to submit a
patch for this to Wine, but escaping escaped quotes sounds like a pain.
The difference in performance won't be noticable, but both lookups and
modifications in these things are much faster once you have more than
one or two elements.
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.
Robbert van der Helm