As per Boost.Asio's manual, an explicit `socket.shutdown()` is needed
before calling `close()`. For some reason this worked fine in almost
every situation, but when hosting both a plugin hosted within a group
host process and a normal individually hosted plugin within a single
process, and then removing those two plugins in order, the
`host_vst_dispatch` socket of the first plugin never got closed. This
would hang the entire shutdown sequence to hang on the
`dispatch_handler` jthread.
First discovered in #45
I'm still really curious why this double reparent would be needed
though. Everything works fine on any other i3 config I've tried, and
even the exact same config in a VM works fine for me.
Boost.Process's `boost::process::environment::at` throws when the
environment variable does not exist, as opposed to `operator[]` which
falls back to an empty value.
For automatic path detection. It's still not recommended to install
yabridge there, but if you know what you're doing then this would at
least be a good default to have.
Not sure why it's doing this, but Renoise seems to report 112 speakers
per audio channel, so the 256 audio channel limit would be exceeded when
using more than 2 output channels.
This is not ideal since it requires the user to know about this option
and to create a config file, but I think it's the best we can do without
compromising on yabridge's transparency and 'zero hacks' philosophy.
See #29 and #32.
This works around Waves plugins causing an infinite message loop. Since
we run the loop 30 times per second anyways splitting the loop up into
chunks of 20 shouldn't be an issue.
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.
This will probably solve the last common setup issue. Starting Wine can
take a second so this check is only repeated when either Wine or
yabridge get updated.
The path check should only take a few milliseconds to run, but checking
whether yabridge-host.exe runs correctly could take over a second when
wineserver isn't already running in the background.
Robbert van der Helm