Request and deserialize plugin factory from plugin

src/plugin/bridges/vst3.cpp

@@ -16,6 +16,42 @@
 
 #include "vst3.h"
 
+#include "src/common/serialization/vst3.h"
+#include "vst3-impls.h"
+
+// There are still some design decisions that need some more thought
+// TODO: Check whether `IPlugView::isPlatformTypeSupported` needs special
+//       handling.
+// TODO: The documentation mentions that private communication through VST3's
+//       message system should be handled on a separate timer thread.  Do we
+//       need special handling for this on the Wine side (e.g. during the event
+//       handling loop)? Probably not, since the actual host should manage all
+//       messaging.
+// TODO: The docs very explicitly mention that
+//       the`IComponentHandler::{begin,perform,end}Edit()` functions have to be
+//       called from the UI thread. Should we have special handling for this or
+//       does everything just magically work out?
+// TODO: Something that's not relevant here but that will require some thinking
+//       is that VST3 requires all plugins to be installed in ~/.vst3. I can
+//       think of two options and I"m not sure what's the best one:
+//
+//       1. We can add the required files for the Linux VST3 plugin to the
+//          location of the Windows VST3 plugin (by adding some files to the
+//          bundle or creating a bundle next to it) and then symlink that bundle
+//          to ~/.vst3.
+//       2. We can create the bundle in ~/.vst3 and symlink the Windows plugin
+//          and all of its resources into bundle as if they were also installed
+//          there.
+//
+//       The second one sounds much better, but it will still need some more
+//       consideration. Aside from that VST3 plugins also have a centralized
+//       preset location, even though barely anyone uses it, yabridgectl will
+//       also have to make a symlink of that. Also, yabridgectl will need to do
+//       some extra work there to detect removed plugins.
+// TODO: Also symlink presets, and allow pruning broken symlinks there as well
+// TODO: And how do we choose between 32-bit and 64-bit versions of a VST3
+//       plugin if they exist? Config files?
+
 Vst3PluginBridge::Vst3PluginBridge()
     : PluginBridge(
           PluginType::vst3,
@@ -34,6 +70,13 @@ Vst3PluginBridge::Vst3PluginBridge()
     // host
     connect_sockets_guarded();
 
+    // Set up the plugin factory, since this is the first thing the host will
+    // request after loading the module
+    plugin_factory = std::make_unique<YaPluginFactoryPluginImpl>(*this);
+    sockets.host_vst_control.receive_into(
+        WantsPluginFactory{}, *plugin_factory,
+        std::pair<Vst3Logger&, bool>(logger, true));
+
     // Now that communication is set up the Wine host can send callbacks to this
     // bridge class, and we can send control messages to the Wine host. This
     // messaging mechanism is how we relay the VST3 communication protocol. As a

src/plugin/bridges/vst3.h

@@ -18,6 +18,7 @@
 
 #include <thread>
 
+#include "../..//common/serialization/vst3/plugin-factory.h"
 #include "../../common/communication/vst3.h"
 #include "../../common/logging/vst3.h"
 #include "common.h"
@@ -63,4 +64,17 @@ class Vst3PluginBridge : PluginBridge<Vst3Sockets<std::jthread>> {
      * `PluginBridge::generic_logger`.
      */
     Vst3Logger logger;
+
+   public:
+    /**
+     * Our plugin factory. This will be set up directly after initialization.
+     * All information about the plugin and its supported classes are copied
+     * directly from the Windows VST3 plugin's factory on the Wine side, and
+     * we'll provide an implementation that can send control messages to the
+     * Wine plugin host.
+     *
+     * A pointer to this implementation will be returned to the host in
+     * GetPluginFactory().
+     */
+    std::unique_ptr<YaPluginFactory> plugin_factory;
 };