setCurrentProgram requires repaint?


#1

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?


#2

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?


#3

This way:

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

I believe that’s normalized.


#4

Thanks, I’ll try that!


#5

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


#6

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


#7

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


#8

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


#9

*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.


#10

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!


#11

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


#12

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


#13

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