Not sure how this got in, and I'm even less sure why this has not caused
any issues before this. In the particular case that was causing a crash,
the host was sending 138 sample sized buffers. This error likely only
became visible because the lack of memory alignment caused writes to
parts of the vector objects themselves.
Since this would only be needed for distribution, and we're already
doing something similar for libstdc++ on the Ubuntu 18.04 build. This
moves the static linking behind a new build option.
This makes the individual plugin host slightly more complex, but now
both individually hosted plugins and plugin groups handle both
dispatcher events and GUI events in the exact same way.
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