Plugin API for dynamic plugin name and code / uniqueID


I wrote a plugin that enables host environments to send OSC control data via automatable host controls at full resolution, as opposed to midi-to-OSC mapping. It uses textual descriptions of the controls based on preset definitions in the YAML markup language. osccontrol-light on GitHub

To create the host-side control elements, the preset to be loaded has to be known at construction time of the plugin, at least using the VST2 implementation that I was able to work with on Linux. The only way to make the preset dynamic, yet available at contruction time, was to encode it in the file name of the plugin that is being loaded. The user creates a copy of the LXVST for every preset that should be available and renames it accordingly.

In order to make this possible, I had to apply two patches to the JuceVSTWrapper.

The first issue is that, instead of returning the compile-time constant JucePlugin_Name, handleGetPlugInName should return what the plugin reports at runtime via the getName() method. Since that API already exists, I was surprised to see that it is not being used at that point.

     pointer_sized_int handleGetPlugInName (VstOpCodeArguments args)
-        String (JucePlugin_Name).copyToUTF8 ((char*) args.ptr, 64 + 1);
+        processor->getName().copyToUTF8 ((char*) args.ptr, 64 + 1);
         return 1;

The second issue is that the unique ID the plugin reports is hard-coded as the JucePlugin_VSTUniqueID or respectively JucePlugin_PluginCode that can only be set statically upon project generation time. Here an API would have to be added to enable a plugin to report a different identifier based on runtime information. While some DAWs don’t have a problem with this (Bitwig Studio differentiates the plugins based on filename only it seems), others do (Ardour uses the Plugin ID for identification and shows only the last-loaded plugin if there are several with the same ID).

I am hoping that the first issue might be resolved with the upcoming support of VST3 on Linux. The second issue needs a new virtual method in PluginProcessor in order to be able to work. The only thing that seems loosely related but AAX-specific is the getAAXPluginIDForMainBusConfig method. Making a virtual getPluginID() method that returns JucePlugin_PluginCode in the default implementation would work just fine for my usecase.

Thank you and best regards,