Send the configuration from plugin to Wine host

Next we can add some options for different plugin editor behaviours for #27.

docs/architecture.md

@@ -57,12 +57,14 @@ as the _Windows VST plugin_. The whole process works as follows:
 
    - Calls from the native VST host to the plugin's `dispatcher()` function.
      These get forwarded to the Windows VST plugin through the Wine VST host.
+
    - Calls from the native VST host to the plugin's `dispatcher()` function with
      the `effProcessEvents` opcode. These also get forwarded to the Windows VST
      plugin through the Wine VST host. This has to be handled separately from
      all other events because of limitations of the Win32 API. Without doing
      this the plugin would not be able to receive any MIDI events while the GUI
      is being resized or a dropdown menu or message box is shown.
+
    - Host callback calls from the Windows VST plugin through the
      `audioMasterCallback` function. These get forwarded to the native VST host
      through the plugin.
@@ -76,6 +78,7 @@ as the _Windows VST plugin_. The whole process works as follows:
      `setParameter()` functions. Both functions get forwarded to the Windows VST
      plugin through the Wine VST host using a single socket because they're very
      similar and don't need any complicated behaviour.
+
    - Calls from the native VST host to the plugin's `processReplacing()`
      function. This function gets forwarded to the Windows VST plugin through
      the Wine VST. In the rare event that the plugin does not support
@@ -83,6 +86,11 @@ as the _Windows VST plugin_. The whole process works as follows:
      `process()` function, then the Wine VST host will emulate the behavior of
      `processReplacing()` instead.
 
+   - And finally there's a separate socket for control messages. At the moment
+     this is only used to transfer the Windows VST plugin's `AEffect` object to
+     the plugin and the current configuration from the plugin to the Wine VST
+     host on startup.
+
    The operations described above involving the host -> plugin `dispatcher()`and
    plugin -> host `audioMaster()` functions are all handled by first serializing
    the function parameters and any payload data into a binary format so they can
@@ -115,9 +123,10 @@ as the _Windows VST plugin_. The whole process works as follows:
 6. The Wine VST host loads the Windows VST plugin and starts forwarding messages
    over the sockets described above.
 7. After the Windows VST plugin has started loading we will forward all values
-   from the plugin's `AEffect` struct to the Linux native VST plugin over the
-   `dispatcher()` socket. This is only done once at startup. After this point
-   the plugin will stop blocking and has finished loading.
+   from the Windows VST plugin's `AEffect` struct to the plugin, and the plugins
+   configuration gets sent back over the same socket to the Wine VST host. After
+   this point the plugin will stop blocking and the initialization process is
+   finished.
 
 ## Plugin groups
 

src/plugin/plugin-bridge.cpp

@@ -180,6 +180,10 @@ PluginBridge::PluginBridge(audioMasterCallback host_callback)
     const auto initialized_plugin =
         std::get<AEffect>(initialization_data.payload);
 
+    // After receiving the `AEffect` values we'll want to send the configuration
+    // back to complete the startup process
+    write_object(host_vst_control, config);
+
     update_aeffect(plugin, initialized_plugin);
 }
 

src/wine-host/bridges/vst2.cpp

@@ -134,6 +134,10 @@ Vst2Bridge::Vst2Bridge(boost::asio::io_context& main_context,
     // `audioMasterIOChanged()`.
     write_object(host_vst_control, EventResult{0, *plugin, std::nullopt});
 
+    // After sending the AEffect struct we'll receive this instance's
+    // configuration as a response
+    config = read_object<Configuration>(host_vst_control);
+
     // This works functionally identically to the `handle_dispatch()` function,
     // but this socket will only handle MIDI events and it will handle them
     // eagerly. This is needed because of Win32 API limitations.

src/wine-host/bridges/vst2.h

@@ -29,6 +29,7 @@
 #include <boost/asio/local/stream_protocol.hpp>
 #include <mutex>
 
+#include "../../common/configuration.h"
 #include "../../common/logging.h"
 #include "../editor.h"
 #include "../utils.h"
@@ -167,6 +168,13 @@ class Vst2Bridge {
      */
     boost::asio::io_context& io_context;
 
+    /**
+     * The configuration for this instance of yabridge based on the `.so` file
+     * that got loaded by the host. This configuration gets loaded on the plugin
+     * side, and then sent over to the Wine host as part of the startup process.
+     */
+    Configuration config;
+
     /**
      * The shared library handle of the VST plugin. I sadly could not get
      * Boost.DLL to work here, so we'll just load the VST plugisn by hand.