This should make the output look much less cluttered since most of the
output would consist of the same path prefix being repeated over and
over again.
The plugin location now also always ends with a trailing slash for
consistency's sake. I don't think Rust's Path has a way to normalize the
paths without also resolving symlinks.
Setting up VST3 plugins without yabridgectl is a lot of work and quite
error prone, so it seems like a good idea to now modify the CI build
artifacts to merge the yabridgectl binary in with the regular archives.
Those also resolves#67.
If `yabridge-host.exe` were somehow to be run with a socket base
directory that's not inside of `$XDG_RUNTIME_DIR`/`/tmp`, then we'll now
warn instead of removing that directory. This should not be necessary,
but in case someone wants to write a wrapper around
`yabridge-host.exe.so` us using a custom `$WINELOADER` then this could
save a lot of headaches.
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.
Or technically, two, since the group bridge also does the same loop. We
no longer need special handling for VST2 and VST3 plugins, so we can
simplify things a bit here.
Even though the interface ID is passed as an FIDString and there is a
function to compare FIDStrings obviously doesn't mean that you're
supposed to use them! Duh.
`std::char_traits<wchar_t>::length()` would return the wrong length for
a wide string under Wine, and thus also for `String128`. This would
cause parts of the strings to get cut off. As a workaround we'll just
serialize the entire container including all null bytes at the end.
Since the restart will always be called from another thread, and when a
plugin asks for a restart during initialization this can quickly lead to
issues.
This is in some cases needed to get decent performance in REAPER, as
REAPER seems to query this information (which cannot change without the
plugin requesting a restart) four times per second.
This can absolutely destroy performance when using VST3 plugins. REAPER
also does something similar with bus information from the audio
thread (for which we had to build in a caching layer), but with these
plugin bridges a VST3 plugin will quickly use ten times as much CPU time
as it should be using.
Robbert van der Helm