Meta-parameters when using ParameterLayout

I’m porting a plugin to 5.4.7 (from 5.3.2), and I’v got it building, but it fails AU validation. I have several parameters that affect other parameters, and that’s causing this error:


# # 24 Global Scope Parameters:

ERROR: Parameter values are different since last set - probable cause: a Meta Param Flag is NOT set on a parameter that will change values of other parameters.

    • FAIL

Under 5.3.2, I was able to set parameter properties like isMetaParameter and isAutomatable, but I don’t see any way to do either of those now. And the classes AudioParameterFloat, etc., all simply return false when asked if they are meta-parameters. I don’t see an easy way to fix that. Do I need to derive all my own parameter classes (like MyAudioUnitFloat) to add that ability to them? Will that even work?

I derived my own classes from AudioParameterInt/Bool/Float/Choice, added an isMeta boolean to each, added a parameter in the constructors to set it, and overrode isMetaParameter to check that, returning the isMeta value.

That seems to work, but it would a lot better if that (and isAutomatable) were allowed to be specified and properly reported via the base class, so this would not be needed in the derived classes (and derived classes would not even be needed then).

1 Like

Changing to feature request.

That would be great! I think to work around the problem with those zillions of constructor arguments, a ParameterOptions struct would make sense, similar to the PopupMenu::Options.

The reason is that I am not sure, when exactly those settings are propagated to the host. Since some hosts might not query those settings ever again, it could be important to have them right from the start.

Having it as constructor argument avoids the two phase initialisation.

1 Like

There are already so many (too much) plugin parameters classes that I feel like making our own derived classes just to handle isMetaParameter() is just adding more confusion. a built-in solution would be great!