With this the plugin groups functionality is feature complete, although
I still want to do a few rounds of refactoring and the readme has not
yet been updated.
This reverts commit e728dbe5a2.
`std::filesystem` is broken on wineg++, at least with Wine 5.8. Any path
operations will throw a `std::filesystem::__cxx11::filesystem_error`:
what(): filesystem error: Cannot convert character sequence: Invalid or incomplete multibyte or wide character
Some plugins would either crash or freeze on the next Win32 message loop
when `effEditGetRect` gets called before `effEditOpen` and we run the
message loop between these two event calls.
Fixes the issue with Superior Drummer 3 in Bitwig mentioned in #12 and a
similar issue with the Roland Cloud synths.
Instead of just detaching the threads, it's much better to terminate the
Wine process and let the threads terminate themselves.
This fixes#11 on my machine.
Now that I think about it it's pretty obvious why symlinks only work
with hosts that support plugin sandboxing (since your OS will never load
two instaces of an identical .so file into the same process). Still, I
find using symlinks in hosts that do sandbox their plugins to be very
user friendly, especially while developing.
This allows symlinking to a copy of `libyabridge.so.` Now we support:
- A symlink to `libyabridge.so` with a `.dll` file in the same directory
as that symlink.
- A symlink to `libyabridge.so` with a symlinked `.dll`.
- A copy of `libyabridge.so` with a `.dll` file in the same directory as
that copy.
- A symlink to a copy of `libyabridge.so` with a `.dll` file in the same
directory as that copy.
- A symlink to a copy of `libyabridge.so` with a symlinked `.dll` file.
That seems a bit overkill, but hey, more options are always better,
right?
Robbert van der Helm