Question/clarification regarding parameter interaction when implementing a plugin host

Hi,

I’m currently implementing a VST3 plugin host (using the bindings from the vst3-rs Rust crate), and I’m at the point where I want to figure out parameter interaction.

Now, I’ve read the documentation on parameters, but either I’m missing something or the information seems contradictory.

In the documentation it says the host is responsible for sharing parameters between edit controller and audio processor, but I didn’t implement anything of that sort and, it … just works? Like, with both ProcessData::inputParameterChanges and ProcessData::outputParameterChanges being nullptr, moving the knobs has an audible result. Feeding parameters into ProcessData::inputParameterChanges moves the knob in the UI without me having implemented any interaction.

I’m mostly testing with JC303, a JUCE based plugin …

Is that due to the specific plugin-implementation and can’t be generalized?

Or am I misunderstanding the documentation?

Best,
N

JUCE based plug-ins use the same memory data for their plug-ins for both edit controller and audio processor. This was state of the art in the late 1990s and early 2000s where the roots of JUCE are. Modern plug-ins will have a separate data section for the data/parameters in their processors and the data/parameters in their controllers. So you should implement the input and output parameter changes mechanism as outlined in the documentation. And depending on the latency of the audio graph you can delay the parameter changes back from the audio processor to the edit controller so that the UI of the edit controller is in sync with the audio.

I hope this helps.

Cheers,
Arne

2 Likes