[Bug]: Edit Controller setParamaterNormalized() Prevents Host Notification of Linked Parameters

[TroikaTronix]

Detailed steps on how to reproduce the bug

The IEM Ambisonic Plugins offer an example with the SceneRotator plugin.

The SceneRotator plugin has the Euler rotation parameters 'yaw', 'pitch', and 'roll'. When any of these change, the related Quaternion values X/Y/Z/W will also change.

When my host calls the Edit Controller's setParameterNormalized function for one of the Euler rotations (e.g., the yaw parameter), this executes bool setNormalized (Vst::ParamValue v) override in juce_audio_plugin_client_VST3.cpp, which in turn calls static void setValueAndNotifyIfChanged (AudioProcessorParameter& param, float newValue).

In the latter function, the InParameterChangedCallbackSetter class sets the inParameterChangedCallback flag to true, which is the source of the issue.

Now, execution continues and the yaw value is stored in the Scene Rotator plugin. Because this affects the quaternion values, they are updated by the SceneRotator using setValueNotifyingHost. One would expect the host to be notified in this case, but that is not the case.

Eventually the setValueNotifyingHost calls leads to void JuceVST3EditController::paramChanged (Steinberg::int32 parameterIndex, Vst::ParamID vstParamId, double newValue) which bails early because inParameterChangedCallback is set.

        if (inParameterChangedCallback || inSetState)
            return;

So, because of this,. the host is not notified of the changes to the quaternion parameters.

I can see why this is done to prevent an endless feedback loop.

But perhaps there is a way to keep a list of what parameter IDs have their "inParameterChangedCallback" so that, when I change the 'yaw' parameter, the quaternion values (with different parameter IDs obviously) would pass through to notify the host and successfully send a beginEdit/performEdit/endEdit sequence.

Perhaps better yet, move the inParameterChangedCallback to the AudioProcessorParameter class? Then you could set this flag per parameter, and easily deny the update if it is true.

What is the expected behaviour?

When calling setValueNotifyingHost, a beginEdit/performEdit/endEdit callback sequence will be executed as long as the specified parameter is not actually the one being modified by a call to the Edit Controller's setParameterNormalized function.

Operating systems

macOS

What versions of the operating systems?

10.14

Architectures

Arm64/aarch64

Stacktrace

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

My custom host, but my repro above would be true for any host.

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[reuk]

I believe this behaviour is simply disallowed by the VST3 spec:

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Parameters+Automation/Index.html#automation

No automated parameter must influence another automated parameter!

So, I'd recommend against exposing both Euler and Quaterion values simultaneously as automatable parameters.

A different approach to consider would be to have a fixed number of "orientation" parameters, and a new control in your UI to switch between the Euler and Quaternion interpretations of these parameters. When the user interacts with the UI control, you can call AudioProcessor::updateHostDisplay() passing a ChangeDetails with the parameterInfoChanged flag set, to ask the host to rescan the parameter names, ranges, mappings, labels, etc. It's not allowed to change the number of parameters at runtime, so you'll end up with a surplus/unused parameter when the plugin is in Euler mode. Remember to store the orientation mode in the plugin's state, so that the automation values have the correct semantics after closing and reloading a project.