Recursive feedback on parameter update from UI

Audio Plugins
1

Hi all,

I’m building an AAX plug-in and everything works as planned, but I have a persistent problem with a parameter update generated from mouse activity in the UI that seems to generate a recursive setvalue/broadcast change cycle. I have a bit of stack here that illustrates the issue;
bottommost call originates in a UI component:

AAXClasses::JuceAAX_Processor::audioProcessorParameterChanged(juce::AudioProcessor*, int, float)
non-virtual thunk to AAXClasses::JuceAAX_Processor::audioProcessorParameterChanged(juce::AudioProcessor*, int, float) ()
juce::AudioProcessorParameter::sendValueChangedMessageToListeners(float)
AAXClasses::JuceAAX_Processor::setAudioProcessorParameter(char const*, double)
AAXClasses::JuceAAX_Processor::UpdateParameterNormalizedValue(char const*, double, AAX_EUpdateSource)
AAXHShell_CAutomationDelegate::PostSetValueRequest(char const*, double) const ()
AAX_VAutomationDelegate::PostSetValueRequest(char const*, double) const
AAX_CParameter<float>::SetValue(float)
AAX_CParameter<float>::SetValueWithFloat(float)
AAXClasses::JuceAAX_Processor::SetParameterNormalizedValue(char const*, double)
AAXClasses::JuceAAX_Processor::audioProcessorParameterChanged(juce::AudioProcessor*, int, float)
non-virtual thunk to AAXClasses::JuceAAX_Processor::audioProcessorParameterChanged(juce::AudioProcessor*, int, float) ()
juce::AudioProcessorParameter::sendValueChangedMessageToListeners(float)
juce::AudioProcessorParameter::setValueNotifyingHost(float)
juce::AudioParameterFloat::operator=(float)
RoomView::setAttemptPosition(juce::Point<float>)

The update is from an x-y pad, which generates two new values from a single mouse action, but they’re set individually, x first, then y. Weird thing is that this doesn’t happen for parameters like single float values from a slider.

If anyone can shed any light on this I’d be grateful.

greetz,

bakker35

2

Is this using the latest version of JUCE?

3

The Juce version is 5.3.2.

I’ve since found that the recursion occurs on value over- or underflows. So if a value outside the min and max allowed for that particular parameter is passed to operator= the recursion happens. So clipping the value before passing it to AudioParameterFloat avoids the problem.

Still worth looking into, I guess.

4

Does it still happen in JUCE 5.4.0? We’ve made some significant parameter changes.

5

Yes, it still happens in 5.4. As soon as the parameter value needs clipping I wind up in the loop.

6

I can’t reproduce this.

I tried doing

*param = 35.0f;

on a mouse event, but I’m not seeing any recursion.

Could you share an example which shows the behaviour, maybe as a PIP?

7

I noticed a similar behavior after the latest update without the invalid value range. It looks like parameter.setValueNotifyHost() now also notifies when the value did not change. Maybe this is the subtle change that can lead to such issues and didn’t in earlier versions. Depending on your code.