This reverts commit eee3d218c1.
This sounded good in theory, but in practice this doesn't work, because
there's no real way to find the matching .dll file form an .so file
without brute forcing it using a bunch of directory listings.
Hopefully this shouldn't be needed, but I didn't realize we only parsed
lower case file names. Wouldn't be surprised if some installer ends up
creating an uppercased `.DLL` file.
I noticed that there were some realtime adhoc-acceptors running on my
system. That should of course not happen, since these only exist to
catch some sporadic (and likely as a result of a badly behaving plugin)
mutual recursion on the audio thread.
This fixes Waves V13 VST3 plugins crashing when opening the editor. They
will likely still crash later on anyways because they're kinda broken.
Amazing.
This wasn't implemented yet because no plugin tried using the interface
in this way before this, but Surge XT incorporates the host's context
menu items into their own (much more elaborate) context menu. To
accommodate this, we now copy over all of the host's prepopulated
context menu items to the Wine plugin host, and calling the targets
associated with any of those items will cause the target on the
associated context menu item on the host to be called.
This is slightly more complicated than what would otherwise be necessary
because Bitwig does not assign tags to their context menu items and
instead always uses 0.
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.
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.
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
Robbert van der Helm