Recursive feedback on parameter update from UI


#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?