Pluginval clarification

Audio Plugins
1

I’ve been getting a fail in plugin val as follows:

!!! Test 8 failed: Bypass not restored on setStateInformation – Expected value within 0.1 of: 0.390118, Actual value: 0

Is it safe to disregard this? At face value, it seems like pluginval is setting the bool parameter to some value, JUCE is snapping that value to 0 or 1 (because it’s a bool), and pluginval is just interpreting this as an error, as the value stored is not the value read. My concern is a similar check may take place from a DAWs plugin scan verification phase, and the plugin ends up blacklisted.

2

Yes, that’s why the fail is still in there.

It seems no one actually knows where that’s valid to do or not.
There’s a long thread on it here with no conclusion:

1 Like
3

We’ve been getting this in pluginval but with non-bool or choice parameters too. I.e. with regular old float params.

I’ve tracked down what I think is the case at least for us.

I spotted the following pattern by adding lots of logging to pluginval (but not too much or the issue would disappear hinting at a timing issue):

  • Parameter Fuzz tests run and finish and param Foo is last set to say 0.12345
  • Next Plugin state restoration tests run and they go basically like this
    • Get original state information from plugin with callGetStateInformationOnMessageThreadIfVST3(instance)
    • Get the value of Foo via parameter->getValue(), turns out it’s still 0.12345
    • Set value of param Foo to 0.6789
    • Restore original state via callSetStateInformationOnMessageThreadIfVST3(instance, originalState)
    • Get the value of Foo and test if it’s within 0.1 of 0.12345 but it turns out it’s 0.5 so test fails
    • Not in the original code but I added code in the case of failure to get and inspect the current state info and in BOTH the original state and current state the value of Foo is 0.5 which is the default value set by the plugin.

I did a bit of digging in the pluginval and JUCE code and it seems like (correct me if I’m wrong) but the cached parameter values accessed via `parameter->getValue()`are updated not if you get or set state info but only in the processBlock functions. So with that in mind I added a sleep of 200ms at the start of the test and after that I can’t reproduce the failure, which suggests the processBlock had a chance to run and update the cached parameter values so the old fuzz set value is updated with the actual value in the plugin.