Hmmm I think the commit is correct. In fact, strictly speaking, any plug-in which strictly conforms to the VST3 SDK needs those lines.
This is because the VST3 edit controller and the VST3 audio processor keep a completely separate set of parameter values. It’s the responsibility of the host to pass on any parameter changes that were done in the editor to the plug-in so that the editor and the plug-in parameters are synced. This is why those lines are needed.
Have a look at the again example in the VST3 SDK (
VST3 SDK/public.sdk/samples/vst/again/source): put a breakpoint at
void AGainEditorView::valueChanged in
againeditor.cpp. This is the slider’s listeners callback. You will see that a change in slider does not pass the value change to the again’s audio processor. It only updates it’s own copy of the gain parameter and then informs the host (via
performEdit) that the value has been changed.
If you put another breakpoint in the loop where parameter event changes are retrieved from the
tresult PLUGIN_API AGain::process (ProcessData& data) in
again.cpp) then you will see that the host passes on the
performEdit change to the audioprocessor via the param queues. This is exactly what the commit does.
Now the problem is that many VST3s out there use some kind of wrapper library (like JUCE) which does not have this separation between the editor and the audio processor. This means that the editor will have already changed the single copy of the gain parameter - and the process function will just change it again. This is - I think - mostly ok as this double change can only happen if the user changes a parameter via the plug-ins editor (for example with the mouse) - which is bound to be inaccurate anyway. The recorded automation data will only receive the changes from the editor (so only once) and when playing back automation data we only use the parameter updates that the audio processor gets.