Cache VST3 parameter information

This is in some cases needed to get decent performance in REAPER, as
REAPER seems to query this information (which cannot change without the
plugin requesting a restart) four times per second.

src/plugin/bridges/vst3-impls/plugin-proxy.cpp

@@ -63,10 +63,9 @@ bool Vst3PluginProxyImpl::unregister_context_menu(size_t context_menu_id) {
     return context_menus.erase(context_menu_id);
 }
 
-void Vst3PluginProxyImpl::clear_bus_cache() {
-    if (processing_bus_cache) {
-        processing_bus_cache.emplace();
-    }
+void Vst3PluginProxyImpl::clear_caches() {
+    clear_bus_cache();
+    clear_parameter_cache();
 }
 
 tresult PLUGIN_API Vst3PluginProxyImpl::setAudioPresentationLatencySamples(
@@ -231,8 +230,8 @@ Vst3PluginProxyImpl::getBusCount(Steinberg::Vst::MediaType type,
             it != processing_bus_cache->bus_count.end()) {
             const bool log_response = bridge.logger.log_request(true, request);
             if (log_response) {
-                bridge.logger.log_response(true, PrimitiveWrapper(it->second),
-                                           true);
+                bridge.logger.log_response(
+                    true, YaComponent::GetBusCount::Response(it->second), true);
             }
 
             return it->second;
@@ -268,11 +267,11 @@ Vst3PluginProxyImpl::getBusInfo(Steinberg::Vst::MediaType type,
             it != processing_bus_cache->bus_info.end()) {
             const bool log_response = bridge.logger.log_request(true, request);
             if (log_response) {
-                bridge.logger.log_response(
-                    true,
-                    GetBusInfoResponse{.result = Steinberg::kResultOk,
-                                       .updated_bus = it->second},
-                    true);
+                bridge.logger.log_response(true,
+                                           YaComponent::GetBusInfo::Response{
+                                               .result = Steinberg::kResultOk,
+                                               .updated_bus = it->second},
+                                           true);
             }
 
             bus = it->second;
@@ -436,19 +435,59 @@ Vst3PluginProxyImpl::setComponentState(Steinberg::IBStream* state) {
 }
 
 int32 PLUGIN_API Vst3PluginProxyImpl::getParameterCount() {
-    return bridge.send_message(
-        YaEditController::GetParameterCount{.instance_id = instance_id()});
+    const auto request =
+        YaEditController::GetParameterCount{.instance_id = instance_id()};
+
+    // We'll cache this information to work around an issue in REAPER, see
+    // `parameter_info_cache`
+    if (parameter_info_cache.parameter_count) {
+        const bool log_response = bridge.logger.log_request(true, request);
+        if (log_response) {
+            bridge.logger.log_response(
+                true,
+                YaEditController::GetParameterCount::Response(
+                    *parameter_info_cache.parameter_count),
+                true);
+        }
+
+        return *parameter_info_cache.parameter_count;
+    }
+
+    const int32 result = bridge.send_message(request);
+
+    parameter_info_cache.parameter_count = result;
+
+    return result;
 }
 
 tresult PLUGIN_API Vst3PluginProxyImpl::getParameterInfo(
     int32 paramIndex,
     Steinberg::Vst::ParameterInfo& info /*out*/) {
-    const GetParameterInfoResponse response = bridge.send_message(
-        YaEditController::GetParameterInfo{.instance_id = instance_id(),
-                                           .param_index = paramIndex,
-                                           .info = info});
+    const auto request = YaEditController::GetParameterInfo{
+        .instance_id = instance_id(), .param_index = paramIndex, .info = info};
+
+    // We'll cache this information to work around an issue in REAPER, see
+    // `parameter_info_cache`
+    if (auto it = parameter_info_cache.parameter_info.find(paramIndex);
+        it != parameter_info_cache.parameter_info.end()) {
+        const bool log_response = bridge.logger.log_request(true, request);
+        if (log_response) {
+            bridge.logger.log_response(
+                true,
+                YaEditController::GetParameterInfo::Response{
+                    .result = Steinberg::kResultOk, .updated_info = it->second},
+                true);
+        }
+
+        info = it->second;
+
+        return Steinberg::kResultOk;
+    }
+
+    const GetParameterInfoResponse response = bridge.send_message(request);
 
     info = response.updated_info;
+    parameter_info_cache.parameter_info[paramIndex] = response.updated_info;
 
     return response.result;
 }
@@ -1117,3 +1156,13 @@ tresult PLUGIN_API Vst3PluginProxyImpl::getXmlRepresentationStream(
         return Steinberg::kInvalidArgument;
     }
 }
+
+void Vst3PluginProxyImpl::clear_bus_cache() {
+    if (processing_bus_cache) {
+        processing_bus_cache.emplace();
+    }
+}
+
+void Vst3PluginProxyImpl::clear_parameter_cache() {
+    parameter_info_cache = ParameterInfoCache{};
+}

src/plugin/bridges/vst3-impls/plugin-proxy.h

@@ -19,6 +19,24 @@
 #include "../vst3.h"
 #include "plug-view-proxy.h"
 
+/**
+ * Here we pass though all function calls made by the host to the Windows VST3
+ * plugin. We sadly had to deviate from yabridge's 'one-to-one passthrough'
+ * philosphy in two places:
+ *
+ * 1. REAPER requests the plugin's input and output bus count and information
+ *    every processing cycle, even though this information cannot change during
+ *    processing. With plugins with many outputs this can lead a lot of extra
+ *    back and forth before the plugin gets to process audio, which thus leads
+ *    to very inflated DSP usage.
+ * 2. REAPER in some situations (because it doesn't always seem to happen)
+ *    fetches the plugin's parameter information exactly four times per second.
+ *    When plugins have thousands of parameters, this unnecessarily uses up a
+ *    lot of CPU time.
+ *
+ * Both of these caches were necessary to get decent performance in REAPER, and
+ * they should be removed as soon as REAPER no longer needs this.
+ */
 class Vst3PluginProxyImpl : public Vst3PluginProxy {
    public:
     Vst3PluginProxyImpl(Vst3PluginBridge& bridge,
@@ -55,23 +73,19 @@ class Vst3PluginProxyImpl : public Vst3PluginProxy {
     bool unregister_context_menu(size_t context_menu_id);
 
     /**
-     * Clear the bus count and information cache. We need this cache for REAPER
-     * as it makes `num_inputs + num_outputs + 2` function calls to retrieve
-     * this information every single processing cycle. For plugins with a lot of
-     * outputs this really adds up. According to the VST3 workflow diagrams bus
-     * information cannot change anymore once `IAudioProcessor::setProcessing()`
-     * has been called, but REAPER doesn't quite follow the spec here and it
-     * will set bus arrangements and activate the plugin only after it's called
-     * `IAudioProcessor::setProcessing()`. Because of that we'll have to
-     * manually flush this cache when the stores information potentially becomes
-     * invalid.
+     * Clear the bus and parameter caches. We'll call this on
+     * `IComponentHandler::restartComponent`. These caching layers are necessary
+     * to get decent performance in REAPER as REAPER repeatedly calls these
+     * functions many times per second, even though their values will never
+     * change.
      *
      * HACK: Once REAPER stops calling these functions, we should remove this
      *       caching layer ASAP as it can only cause issues
      *
-     * @see processing_bus_cache
+     * @see clear_bus_cache
+     * @see clear_parameter_cache
      */
-    void clear_bus_cache();
+    void clear_caches();
 
     // From `IAudioPresentationLatency`
     tresult PLUGIN_API
@@ -383,6 +397,33 @@ class Vst3PluginProxyImpl : public Vst3PluginProxy {
     Steinberg::FUnknownPtr<Steinberg::Vst::IUnitHandler2> unit_handler_2;
 
    private:
+    /**
+     * Clear the bus count and information cache. We need this cache for REAPER
+     * as it makes `num_inputs + num_outputs + 2` function calls to retrieve
+     * this information every single processing cycle. For plugins with a lot of
+     * outputs this really adds up. According to the VST3 workflow diagrams bus
+     * information cannot change anymore once `IAudioProcessor::setProcessing()`
+     * has been called, but REAPER doesn't quite follow the spec here and it
+     * will set bus arrangements and activate the plugin only after it's called
+     * `IAudioProcessor::setProcessing()`. Because of that we'll have to
+     * manually flush this cache when the stores information potentially becomes
+     * invalid.
+     *
+     * @see processing_bus_cache
+     */
+    void clear_bus_cache();
+
+    /**
+     * Clears the parameter information cache. Normally hosts only have to
+     * request this once, since the information never changes. REAPER however in
+     * some situations asks for this information four times per second. This
+     * extra back and forth can really add up once plugins start having
+     * thousands of parameters.
+     *
+     * @see parameter_info_cache
+     */
+    void clear_parameter_cache();
+
     Vst3PluginBridge& bridge;
 
     /**
@@ -431,15 +472,45 @@ class Vst3PluginProxyImpl : public Vst3PluginProxy {
     };
 
     /**
-     * HACK: To work around some behaviour in REAPER where it will repeatedly
-     *       query the same bus information for bus during every processing
-     *       cycle, we'll cache this information during processing.  Otherwise
-     *       this will cause `input_busses + output_busses + 2` extra
-     *       unnecessary back and forths for every processing cycle. This can
-     *       really add up for plugins with 16, or even 32 outputs.
+     * To work around some behaviour in REAPER where it will repeatedly query
+     * the same bus information for bus during every processing cycle, we'll
+     * cache this information during processing. Otherwise this will cause
+     * `input_busses + output_busses + 2` extra unnecessary back and forths for
+     * every processing cycle. This can really add up for plugins with 16, or
+     * even 32 outputs.
      *
      * Since this information cannot change during processing, this will not
      * contain a value while the plugin is not processing audio.
+     *
+     * HACK: This is only necessary because REAPER requests this information
+     *       once per procession cycle. We can get rid of this once it no longer
+     *       does that.
      */
     std::optional<BusInfoCache> processing_bus_cache;
+
+    /**
+     * A cache for `IEditController::getParameterCount()` and
+     * `IEditController::getParameterInfo()` to work around an implementation
+     * issue in REAPER. In some situations REAPER will query this information
+     * four times a second, and all of this back and forth communication really
+     * adds up when a plugin starts having thousands of parameters.
+     *
+     * @see parameter_cache
+     */
+    struct ParameterInfoCache {
+        std::optional<int32> parameter_count;
+        std::map<int32, Steinberg::Vst::ParameterInfo> parameter_info;
+    };
+
+    /**
+     * A cache for the parameter count and infos. This is necessary because in
+     * some situations REAPER queries this information four times per second
+     * even though it cannot change. This happens when using the plugin bridges,
+     * but it can also happen in some other cases so I'm not quite sure what the
+     * trigger is.
+     *
+     * HACK: This is only necessary because REAPER sometimes requests this
+     *       information four times per second.
+     */
+    ParameterInfoCache parameter_info_cache;
 };

src/plugin/bridges/vst3.cpp

@@ -88,9 +88,9 @@ Vst3PluginBridge::Vst3PluginBridge()
                     Vst3PluginProxyImpl& proxy_object =
                         plugin_proxies.at(request.owner_instance_id).get();
 
-                    // To err on the safe side, we'll just always clear out bus
-                    // info cache whenever a plugin requests a restart
-                    proxy_object.clear_bus_cache();
+                    // To err on the safe side, we'll just always clear out all
+                    // of our caches whenever a plugin requests a restart
+                    proxy_object.clear_caches();
 
                     return proxy_object.component_handler->restartComponent(
                         request.flags);