setCurrentProgram requires repaint?

Hi,
Small question, I’m adding presets to my plugin, but when I call setCurrentProgram and set the state with *parameters.getRawParameterValue (“power”) = 10;, there is no repaint, probably because no one is listening yet.
What is the proper pattern to update the GUI?

Tried static_cast<::juce::AudioParameterFloat>(parameters.getParameter(“power”)) = 10; andsetValue, but both of them seem to change the parameter as if the value is between 0 and 1 (host range), so which way triggers the updates?

This way:

parms.getParameter("power")->setValueNotifyingHost(0.5f);

I believe that’s normalized.

Thanks, I’ll try that!

Well, it’s not :confused:
So no one knows how to properly set a value from a program??

It’s not changing the value or the parameter? Or the GUI isn’t changing?

It is changing, but just as setValue, so you need to scale your values between 0 and 1, contrary to the *getRawParameterValue call.

with *getrawparametervalue, the GUI is not updated, but the values are changed (if you open and close the editor, the values are correctly set).

*getrawparametervalue is just returning the value of the parameter to you…it’s not changing anything.

Going back to your original question about setCurrentProgram, I would imagine that the most common way for dealing with programs/presets is via the ValueTree that’s part of the AudioProcessorValueTreeState. If you take a look at the tutorial https://www.juce.com/doc/tutorial_audio_processor_value_tree_state, you can see that saving and restoring the state of your parameters becomes very simple, literally a couple of lines of code because you’re not setting every parameter by hand, one by one.

Agreed, I’m not sure why there isn’t a corresponding setValue() function that takes into account the NormalizableRange that was used when the parameter was created. Honestly, there’s a few more goodies that could be added to that class to make it a little more robust for production, but maybe the JUCE team figures that everyone will add whatever specific functionality they need for themselves. I know I made a wrapper class for the AudioProcessorParameterWithID for myself that holds on to the range, previous value, MIDI CC stuff, etc…

But essentially, thanks to the ValueTree and the SliderAttachments, I have very few places in my plugin where I explicitly set a parameter and it works pretty well.

Hope that helps.

Well, for loading from the state, you can use getRawParameterValue to set it, and it works perfectly fine (which is why it’s a float and not just a float or a const float*).

So I should create a ValueTree instead and set it. That would make sense indeed… Thanks, I’ll try that.

Side note: yes, agreed that the value tree state is missing some goodies. For instance, I would love to be able to get a subchannel if I could store parameters as a hierarchy. No point in having everything flattened when you know some work together!

Creating a custom value tree to match what’s inside the valuetreestate is… complicated… There are no examples on this as well?

Are you calling AudioProcessor::updateHostDisplay after updating the parameters?

No, but I don’t want to update the host display, I want to update the GUI display (so my editor).