I think the idea is that normally the plugin will keep copies of the
pointers to the `VstMidiKeyName` structs passed after initialization,
and the host will just read from them whenever it needs to draw these
labels. Since there's no explicit synchronization or notification going
on there's no way for us to tell that these have changed. It would be
possible to implement this by storing these pointers on the plugin side,
storing the objects on the Wine host side, and then periodically polling
for updates. Right now I chose to just not bother with this because it
will add a lot of complexity for very minimal gain (I only noticed it
was an issue after messing with MDrummer and switching between the pad
and loop modes).
It's a bit clearer this way. I would prefer using jthreads here, but we
would still need this try-catch block since there's no way to cancel
synchronous Boost.Asio socket operations other than closing the socket.
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.
Now that Ubuntu 20.04 is out every currently supported distro that's not
based on Ubuntu 18.04 is shipping GCC 10, so we can start using some
C++20 features. Ubuntu 18.04 already needed a newer version of GCC
installed through a PPA and a newer version of Boost to compile
yabridge, so requiring GCC 10 shouldn't be an issue.
I did not know that `std::optional::value()` did checked access. And I
still prefer a more explicit .has_value() over boolean conversion, but
this seems to be the accepted way to do this.
Somehwere between yabridge 1.1.4 and 1.2.0 we apparently started
requiring newer libstc++ features, and I kind of forgot that libstdc++
needed is bound to the version of g++ the program was compiled with.
Statically linking libstdc++ could in theory cause issues, but I think
we'll be fine.
With yabridge 1.2.0 I'll change the regular `yabridge` package to
compile from the source tarball and I'll a new `yabridge-bin` package
that just uses the binaries from the GitHub releases section to confrom
with the usual package naming conventions.
This cleans up the PluginBridge significantly by getting rid of all
fields and handling that was only needed for connecting to plugin
groups. This was also the last thing I wanted to refactor before
releasing the plugin groups feature with yabridge 1.2.
This reverts commit 0c047f9a66.
This workaround was needed because of the weird threading behavior with
the Win32 APIs, std::thread and winelib. Now that the actual
`active_plugins.erase()` call is done from within the plugin
context/main thread, this hack is no longer needed.
Not sure why I made this more complicated than it needed to be to begin
with. And just like in `Vst2Bridge`, we can't reliably run third party
code inside of an `std::thread` so the IO context and initialization has
to be run on the main thread.
Robbert van der Helm