From cd02ab5fc97684ba10395a965be158d8070fa428 Mon Sep 17 00:00:00 2001 From: Robbert van der Helm Date: Wed, 22 Jul 2020 17:15:20 +0200 Subject: [PATCH] Send the configuration from plugin to Wine host Next we can add some options for different plugin editor behaviours for #27. --- docs/architecture.md | 15 ++++++++++++--- src/plugin/plugin-bridge.cpp | 4 ++++ src/wine-host/bridges/vst2.cpp | 4 ++++ src/wine-host/bridges/vst2.h | 8 ++++++++ 4 files changed, 28 insertions(+), 3 deletions(-) diff --git a/docs/architecture.md b/docs/architecture.md index 75cbcd98..27f69cf9 100644 --- a/docs/architecture.md +++ b/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 diff --git a/src/plugin/plugin-bridge.cpp b/src/plugin/plugin-bridge.cpp index 48128fac..3f150c0b 100644 --- a/src/plugin/plugin-bridge.cpp +++ b/src/plugin/plugin-bridge.cpp @@ -180,6 +180,10 @@ PluginBridge::PluginBridge(audioMasterCallback host_callback) const auto initialized_plugin = std::get(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); } diff --git a/src/wine-host/bridges/vst2.cpp b/src/wine-host/bridges/vst2.cpp index 1e4580a1..a2daefe7 100644 --- a/src/wine-host/bridges/vst2.cpp +++ b/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(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. diff --git a/src/wine-host/bridges/vst2.h b/src/wine-host/bridges/vst2.h index 3478e72b..3ecc98ed 100644 --- a/src/wine-host/bridges/vst2.h +++ b/src/wine-host/bridges/vst2.h @@ -29,6 +29,7 @@ #include #include +#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.