Hi,
It would be nice to have a simple AudioParameterBool::toggleNotifyingHost()
method for toggling the true/false value of the parameter instead of param->setValueNotifyingHost(!param->get())
which seems to be the only way to do it at current!
Hi,
It would be nice to have a simple AudioParameterBool::toggleNotifyingHost()
method for toggling the true/false value of the parameter instead of param->setValueNotifyingHost(!param->get())
which seems to be the only way to do it at current!
Also, could we get an incrementBy()
method (that takes +ve and -ve values) for AudioParameterFloat
and AudioParameterInt
?
These both have the get()
method to get the non-normalised value of the parameter but no way to set the value using non-normalised values (AFAIK).
At the moment I’m using:
auto newValue = param->get() + valueToAdd;
auto normalisedNewValue = (newValue - param->getRange().getStart()) / (float)param->getRange().getLength();
param->setValueNotifyingHost(normalisedNewValue);
It would be nice to be able to do:
param->incrementValueBy(valueToAdd);
Or at least:
param->setNonNormalisedValue(param->get() + valueToAdd);
+1 I’ve had these features in my own parameter management code for a while & they’ve been super useful
Cheeky bump…
Any arguments for or against this from the JUCE team?
They seem like sensible suggestions, but they’re bordering being so simple that they wouldn’t be a good addition to JUCE - if we implemented all requests the API would quickly get too bloated.
For incrementing a parameter you can simply do:
AudioParameterInt param (...);
DBG (param.get());
param = param.get() + value;
DBG (param.get());
And likewise for AudioParameterBool
:
AudioParameterBool param (...);
DBG ((param.get() ? "Yes" : "No"));
param = ! param;
DBG ((param.get() ? "Yes" : "No"));