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.
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.
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 sadly cannot call `shared_library()` and `executable()` in these
subdirectories while still maintaining the same `build/` directory
structure, but this is still much cleaner. All of the other build
artifacts are now also gone from the root of `build/` so it's cleaner
overall.
Since we're using the XDG base dir package in yabridgectl we were
already doing this there, so it makes sense to also do this in yabridge
itself even though it's very unlikely the user will have this set.
These critical notifications don't expire under KDE Plasma, which would
mean that you'd get absolutely flooded with notifications you have to
manually close when something is wrong.
This makes the initialization message reflect the correct Wine version
when using a `WINELOADER` script to change between Wine versions
depending on the Wine prefix.
- Don't call bp::search_path when using WINELOADER. It will return an
empty string for an absolute path.
- To match the behaviour of the exe wrapper scripts, only print the
wine version from WINELOADER if the path is executable.
Otherwise we would always use the 64-bit version and there would be no
way to use the 32-bit version, if version for some reason works better.
Relates to #80.
There is some sort of memory corruption going on and these plugins
usually segfault on the audio thread. I'm clueless as to what could be
causing this (I wouldn't be surprised if this is caused by an
interaction between the VST3 SDK and Wine's Windows.h implementation),
but it's probably best to disable loading 32-bit VST3 plugins completely
until this has been fixed.
To account for the differences in VST2 plugins and VST3 modules we had
to wrap most of our old functions from `src/plugin/utils.h` in a new
`PluginInfo` struct that gathers all of this information while taking
into account the differences between VST2 and VST3 plugins.
With this change things are also a lot more organized. We can just query
the plugin information we need rather than having to store things
separately or having to recalculate things. This also moved the
responsibility of all the weird `WINEPREFIX` behaviour to a single place
instead of having it spread around `utils.pp`, the initialisation
message, and `host-procoess.cpp`.
This is a pretty huge change that will be important for being able to
handle nested or mutually recursive `dispatch()` and `audioMaster()`
calls. This sadly all had to be done in a single commit, so here's a
summary:
- `src/common/sockets.h:Sockets` contains all sockets on both the plugin
and the Wine host side, and is used to both listen on and connect to
the sockets.
- Sockets and other temporary files respect `$XDG_RUNTIME_DIR` instead
of being dumped in `/tmp`.
- All sockets now have a unique endpoint in
`/run/user/<uid>/yabridge-<plugin_name>-<random_id>/`. This is
important for when we want to have multiple socket connections for
handling `dispatch()` and `audioMaster()`.
- Because of the above, we no longer clean up the socket endpoint files
after the connection gets established during initialization. Instead
we'll remove the socket base directory when shutting down.
This significantly reduces the latency with no real drawbacks from what
I've noticed. Wineserver is still run using the normal scheduling
policies because from my testing running that with realtime priority
that can actually increase latencies, although doing so will greatly
reduce the variance in processing time.