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.
Running the audio processing and midi dispatcher loops in a regular
`std::thread` causes weird memory corruption issues (likely because of
calling conventions are not being respected). Luckily this does not
cause any issues here, so we can get rid of a lot of ugly glue code and
manual memory management.
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.
Should not matter that much, but a potential situation where you would
want to have handled the X11 events first is when the editor enters a
blocking message loop while it is waiting on a GUI component just as the
window gets moved by an external program or window manager.
At a 30 fps rate with a limit on the number of window messages per
frame. This is somehow needed for Melda plugins, as they otherwise
dispatch tiemr messages indefinitely after opening a second editor with
seemingly no way around it.
With this and some refactoring #15 should be almost done.
This is a bit more restrictive than the old approach that only skipped
when `effEditOpen()` got called after `effEditGetRect()`. Not sure why
the Melda plugins block indefinitely on the message loop without this
now.
Robbert van der Helm