Why does ParameterID::version default to 0 and assert like there's no tomorrow?


We’re exploring upgrading to JUCE 7. Now when we start our plug-ins we get loads of asserts in AudioProcessor::validateParameter(). OK great, my awareness of the issue has been risen! The problem is though that some of our plugins have loads of parameters with their definitions scattered over different modules. adding a version hint to each of them seems to be a mind-numbing and time-wasting endeavour.

As I understand it, the parameter indices! are sorted by (version, paramIdHash), so having a version hint of 0 (which is the current default) yields the previous ordering. Then adding a parameter with (1, someNewParamId) would add the new parameter to the back of the array.

So isn’t the assert a bit pointless (other than raising awareness of course) ? Can we get an option to disable this or at least fire only once ?

Thanks and all the best,

addendum: Why is there the wrapperType == wrapperType_Undefined expression? When would this be the case?

addendum 2: I propose to change the assert into the following:

    /*  If you're building this plugin as an AudioUnit, and you intend to use the plugin in
        Logic Pro or GarageBand, it's a good idea to set version hints on all of your parameters
        so that you can add parameters safely in future versions of the plugin.
        See the documentation for AudioProcessorParameter(int) for more information.
   #if JucePlugin_Build_AU
    static auto warningShown = false;
    if (!warningShown && !(wrapperType == wrapperType_Undefined || param->getVersionHint() != 0))
        DBG("WARNING: one or more of your parameters IDs do not have a version hint. Set a breakpoint in ");
        DBG("  " << __FILE__ << ":" << __LINE__);
        DBG("to learn more.");
        warningShown = true;

Or am I missing something ? Do I really MUST add version hints to all the parameters if I ever want to add parameters to the AU versions in the future ?

See How to set a parameter version hint?

edit: sorry, I didn’t actually read your post properly and that doesn’t help in the slightest :man_facepalming:

Raising awareness is the main purpose of the assertion. We assume that users shipping AU plug-ins will want to know about this issue. Reducing the number of assertions is a good idea, though. It’s been suggested previously, but it’s never made it to the top of my to-do list.

This is the case when using an AudioProcessor for some purpose other than being wrapped into a plug-in. For example, a plug-in might use the AudioProcessorGraph to host multiple AudioProcessors internally. Only the outermost AudioProcessor will have its wrapperType set, and the processors hosted by the graph will have their type set to undefined.

We’ll do something a bit like that, but use an assertion rather than printing into the console.

It’s a bit safer to set all of the hints to a non-zero value. That way, if you add a new parameter in the future and accidentally forget to set its hint, you’ll hit the assertion and won’t ship a broken plugin. If you keep all of your existing parameters with their hints set to zero, then the assertion(s) raised by these parameters will hide any assertions triggered by new, unhinted parameters in the future, so you might not realise that the parameter order has been broken until it’s too late.