I am currently developing an Audio-Plugin with JUCE where automations are started within the AudioPluginProcessor. These automations update parameter values (AudioProcessorParameter) in each call of processBlock(). For example, audio files are played and the current position of the played audio file is given as a parameter to the host. These parameters are used for reading out via gRPC over Sushi.
Now I have the problem that ELK Sushi don’t recognize if automated parameters get changed by the plugin itself and won’t display the right parameter value. Even if I notify Sushi with a JUCE method setValueNotifyingHost() that a parameter was updated.
The JUCE AudioPluginHost updates the parameters correctly, as well as Ableton with a closed and open UI. Buf if I test it in Sushi, the parameters are not updated. Is there a way to tell Sushi to update the values?
Hi valentin. What you’re trying to do is indeed possible. There is support in Sushi for changing the values of parameters from within a plugin and have that sent over gRPC. This is supported for both VST2 and VST3 plugin formats. Which format are you compiling your plugin into?
Are you using gRPC directly or through our elkpy wrapper? Are you using the notification functions or simply querying the parameters values?
I’m compiling a VST3 plugin, but VST2 would also fit!
I compiled Sushi for Linux (aarach64) and using the elkpy wrapper (https://github.com/elk-audio/elkpy) to receive and send the parameters. While developing, I am also using the GRPC Web UI. There I use sushi_rpc.ParameterController -> setParameterValue or getParameterValue. When parameters get changed within the JUCE Audio Plugin, these changes are not displayed when callin getParameterValue
Are you able to build a vst 2 version of your plugin and test that? You can also test the notification part of elkpy and register a callback with NotificationController.subscribe_to_parameter_updates() and see if that gets triggered.
If it does work for vst2 then I may have a hunch to what’s going on. In that case you will get a gRPC notification, but vst3 requires the host to send the parameter changes back to the non-rt part of the plugin and that is not done afaik. Probably an oversight on our part.
You shouldn’t need to call anything outside of the plugin api’s function to set the parameter from inside the plugin. In vst2 that would be setParameterAutomated() and in vst3 you would add it to the outputEvents member of ProcessData. I don’t now the exact JUCE function, but I guess it maps to one of those.
Hi @Gustav , I finally got around to testing the plugin as VST2.4 under Sushi. In fact, it is possible to retrieve parameter changes made by the plugin itself via gRPC.
However, with the same JUCE audio plugin compiled as VST3, this does not work. The plugin tested in Ableton, updates the parameters.
So my question, is Sushi able to capture internal parameter changes of VST3 plugins?
In the long run, I would not like to use an old VST standard. In addition, Steinberg no longer grants licenses for VST2 plugins and therefore it is actually no longer possible to rely on this standard.
Thanks for testing Valentin. I have working on our Vst implementation for another story and from that think I have a pretty good grasp of what the problem is here.
In short, the issue is that Vst 3 plugins have 2 parts, an audioprocessor and a controller, Each having their own copy of the whole set of parameter values. If you set a parameter from within the audio processor, Sushi does not forward the updated value to the controller part of the plugin, which was an oversight on out part.
Can you live with it only working for Vst2 for the moment? We will likely have a fix for the next version of Sushi coming out.