Pluginval failure with serialization of boolean parameters

[benvining]

My plugin has several boolean toggle parameters, which in my code I’m dealing with as juce::AudioParameterBool objects. I noticed that if I “quantize” the float values (ie, saving the value as a boolean and reloading to either 0.f or 1.f), then pluginval tests fail (on strictness level 10) with output saying it tried to save values such as 0.2 or 0.7 but they got recalled as 0.f and 1.f. I suppose this is somewhat understandable from pluginval’s perspective, but I’m wondering if it’s a flawed approach to “quantize” the values to 0 and 1 in this way – saving the exact floating point value seems somewhat irrelevant if it functions as a boolean toggle to the plugin?

[sudara]

Cross-linking as it might be relevant: Basic AudioProcessorValueTreeState plugin won't pass PluginVal - #5 by lalala

[hugoderwolf]

See also here:

Pluginval can set an AudioParameterBools to odd values

I’m debugging a strange issue that sometimes leads to Pluginval’s state restoration test to fail. This is with an AU plugin, I’m not sure yet if it also happens with the VST3. The test checks if the sum of parameter values is the same before and after a state restore. Under some circumstances, when the test starts, the two AudioParameterBools that the plugin uses have random values that are not 0.f or 1.f. After saving and restoring the state they are correctly set to either 0.f or 1.f, and thu…

It’s been a while, and I ended up with a custom AudioParameterBool implementation that includes the fix as proposed in the thread. Then forgot about it and didn’t follow through to get this rather simple fix into mainline JUCE.