Thanks lalala,
yes, there are workarounds for the issue. But personally I prefer fixing the issue itself.
Will this be fixed across all plugin wrappers, or should my plugins do that work?
As I said - this is something we will look at, and when we fix it we will harmonise the behaviour across all plug-in formats. However, we have a lot of higher priority work to do first so I can’t give a sensible estimate of when this might be. Please be patient.
Thanks for the clarification.
I’ve just pushed a change to the develop branch which unifies the behaviour across all plug-in formats.
parameterChanged() callbacks will only be called if the parameter’s value is different from its default value when you either create a plug-in or load a plug-in from a saved state.
If you require parameterChanged() callbacks for initially default values then you need to manage this yourself.
Perhaps this could be added to the doc of AudioProcessorValueTreeState::parameterChanged()?
do we have the same behaviour with AudioProcessorParameter::Listener::parameterValueChanged() ?
edit:
another small documentation suggestion for AudioProcessorValueTreeState:
indicate that the parameter returned by :
AudioProcessorParameterWithID* AudioProcessorValueTreeState::createAndAddParameter()
will be managed and deleted automatically by the processor when no longer needed.
Dear all,
I’m reactivating this somehow old since I encountered a similar problem (with the new way of parameter handling).
@t0m: thanks for providing the solution (i.e. trigger parameterChanged()), it works like a charm.
Nevertheless I am wondering why it is mandatory, while creating the ParameterLayout during the object’s construction, to provide a default value to all parameters. At this point, no listeners have been set yet, and the only reason I could imagine then would be to initialize the GUI. But then it would be a little bit confusing, since there may be a mismatch between the GUI and the inner state of the object (if the listeners do something else as updating a value, which my case here).
Wouldn’t it make sense either not to provide a default value while initializing the parameter, or, when a listener has been added to the parameter, automatically trigger it with the default value?
I’m quite new in JUCE and the new way of handling parameters (from version 5.4) may still lack useful user’s feedback and tips on this forum, so it’s probable that I don’t fully understand the full logic of the way JUCE handles parameters. I’d be pleased to get some better insight in it from experts.
Best
Alexis Baskind