GroupHost::running() would sometimes cause plugins to get terminated
prematurely when connecting to another plugin's group host process since
the plugin's own group host process has exited.
This will also cause plugins to update their editors at 60 FPS. This was
kept at a lower value for performance reasons, but since the message
loop now no longer blocks event handling we can safely increase this.
This will double the amount of resources spent on drawing, but since
audio processing in a real world scenario almost never utilizes all
cores anyways this should not be an issue.
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.
Robbert van der Helm