With this the basic IComponent interface is fully implemented. Next will
be `IAudioProcessor` and `IConnectionPoint` as additions to IComponent.
We'll use the same `known_iids` mechanism as used in the plugin factory.
Directly serializing and deserializing into objects was and more
boilerplate heavy (since we now need two implementations even though we
only use one), and also much less flexible because we can't wrap
payloads in structs or provide optional values that way.
This is less likely to clash with names used by interfaces and it's a
bit clearer what's going on (since they are basically proxies for
constructors and destructors).
This was a nasty race condition that only seemed to pop up with Spitfire
plugins in REAPER, but it could also happen elsewhere. The
`active_plugins_mutex` was getting locked from the message loop, but the
plugin would block until `effOpen()` had been called. But because the
mutex was locked by the message loop we would never get to handling
`effOpen()`. Passing the pointer directly both removes this unnecessary
locking and fixes the issue.
Transferring some argument pack is much easier than trying to
deserialize into an existing object when you also have to transfer more
information than just that object.
This now takes a regular overloaded function and the visiting is done in
`receive_messages()` itself. This way we can use templates to ensure
that the return type is correct. Otherwise auto will cause issues in the
future when we want to return multiple concrete types from a function
that takes a single variant. The alternative would be both receiving a
variant as a parameter and then returning another variant as a result,
but that is much less type safe.
And add separate implementations for the native plugin and the Wine
plugin host. This way we can easily allow the native host to do
callbacks without having to manage a load of lambdas.
This took me a few hours of non-stop headaches to figure out. Apparently
deep inside of Wine's headers having __MINGW32__ defined will cause some
GUIDs to be defined slightly differently. This normally wouldn't cause
issues, but when including `shellobj.h` or `objbase.h` this results in
multiple definition linking errors that are basically impossible to
diagnose.
Robbert van der Helm