AudioProcessorValueTreeState::Parameter: juce_VST3_Wrapper calls setParamNormalized when newValue isn't

Hi,

We’ve just changed our plugins to use the new method of creating our AudioProcessorValueTreeState Parameters, using JUCE 5.4.4. (This thread was a big help)

Now, when using
std::make_unique<AudioParameterFloat> ("inputgain", "Input Gain", nRange_Input, nRange_Input.snapToLegalValue(0.0f))
(with nRange_Input being a NormalisableRange<float>),
it all works fine, the sliders and parameters behave as expected, in AU + VST3.

But since we want some of out parameters to be non-automatable, we decided to use
std::make_unique<AudioProcessorValueTreeState::Parameter> ("inputgain", "Input Gain", "dB", nRange_Input, nRange_Input.snapToLegalValue(0.0f), [](float value) { return String(value); }, nullptr, false, false, false).

These are the same parameters we used before when calling CreateAndAddParameter, which didn’t lead to the issue we have now.

In AU, there’s no problem.
In VST3, Mac+Windows, while dragging any Slider, it jumps around between its minimum and maximum values.

Digging around with the debugger has lead me to juce_VST3_Wrapper.cpp:869, which (sometimes) calls EditController::setParamNormalized, when the newValue that comes in, isn’t normalized at all.

Also this seems to induce a little unfortunate feedback loop: (formatted as quote for readability reasons)

So here is a little story of what happens.
I have an input gain Slider with a Range of -24dB…+24dB.
Its value is 0.0dB, the slider is in its middle position.
I use the textbox to enter “-1” and press return.

  • Slider::setValue gets called. newValue is -1
  • Slider::setValue gets called. newValue is -1
  • JuceVST3EditController::paramChanged calls EditController::setParamNormalized. newValue is -1
  • Slider::setValue gets called. newValue is -24 (because of course it is)
  • JuceVST3EditController::paramChanged calls EditController::setParamNormalized. newValue is -24
  • JuceVST3EditController::paramChanged calls EditController::setParamNormalized. newValue is -0.479166657
  • Slider::setValue gets called. newValue is -1
  • JuceVST3EditController::paramChanged calls EditController::setParamNormalized. newValue is -1
  • Slider::setValue gets called. newValue is -24
  • JuceVST3EditController::paramChanged calls EditController::setParamNormalized. newValue is -24
  • Slider::setValue gets called. newValue is -24
    …aaaand we’re done.

Now, to the questions :slight_smile:
• Is there any way yet to make an AudioParameterFloat, using the new constructor, non-automatable?
• If not, any ideas on how to handle this situation? Do we have to modify our plugins to use normalized values for all of our Sliders, or is there another way?

TIA!

We are having a very similar problem; the key difference is that this happens to AudioProcessorValueTreeState parameters that worked fine in 5.4.3; we just shipped a product with 5.4.3 last week that, when built against 5.4.4, has this feedback loop issue.

Here is a screenshot of the automation data that is written when turning a knob. This particular build is the VST2. You can plainly see the feedback; the host is getting sent real world values as a result of its 0,1 sends.

1 Like

We’ve also been experiencing a similar problem (I think since 5.4.4). @microlomaniac did you ever get to the bottom of this or find a solution?

It is fixed on the Dev branch. They said they were going to push a hot fix, but I haven’t seen it come down the pike on Master. Currently building on Dev.

See this thread for more discussion:

We’re planning to merge develop into master in a week or so.

1 Like

Thanks @crandall1 for the detailed report and @t0m for quick fixing. Unfortunately this doesn’t fix the issue for me. I will have a more detailed look at this tomorrow morning and report back. It’s possible I’m doing something wrong!

@microlomaniac did the above fix work for you?

If you could get a test case showing something amiss that would be very helpful.

Actually it turns out that fix does work for me. For some reason I had a stale copy of the updated files. A full delete, clean and build sorted it.

Thanks again @t0m for the quick response.

Just a little update: All is fine with Juce 5.4.5 - thanks!