This avoids doing the duplicate check (since both `setProcessing()` and
`setActive()` would be called), and this also gets rid of the assumption
added a couple commits ago that `setupProcessing()` is only ever called
once, which is not true.
We need to silence the warning about this because Steinberg doesn't
declare their base class destructors as virtual (because of Windows ABI
compatibility issues). But we can still do it inside of yabridge to have
at least a bit more safety.
They were 95% the same, so this makes a lot more sense this way. When
group host processes were introduced yabridge only did VST2 bridging,
but we already have a plugin type argument anyways so might as well
reuse that for group hosts.
Now we no longer rely on anything from Boost. Later we'll move the path
detection to the very beginning of the plugin bridge initialization so
it can be set from the coming chainloader libraries.
We had to add an even hackier hack now to get Boost.Process to
interoperate with Asio's IO contexts. This will be replaced later when
we replace Boost.Process.
With the `ghc::filesystem` dependency from the previous commit. If we
can replace the rest of the Boost.Filesystem dependency then we can get
rid the one nasty runtime dependency we have, and it will make
implementing the chainloading simpler since can reuse more code without
bringing in Boost.
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.
I'm not a fan of Hungarian notation, but C++ kind of needs it with its
implicit `this`. And of all the common options for this, I find
suffixing members with an underscore the least offensive one.
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.
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
Robbert van der Helm