Error when validating AAX plugin ("Number of parameter steps exceeds limit")


#1

Hi,

so I was finishing up the AAX version of my plugin today and thought “let’s run it through the AAX validator tests as a last check”. The plugin has been working just fine for me and my beta-testers, in the latest Pro Tools versions (and even in Pro Tools 10 on Windows using the 32-bit version), but apparently the AAX validator tools gave me a failure on 1 test where it complains about all of my parameters, saying something like this:

parameter:
        -
          number_of_steps: 2147483647
          parameter_name: InGain
          parameter_result: "ERROR: Number of parameter steps exceeds limit"

That number of steps is 2^31 - 1 (so the max. value of a signed 32-bit integer).
This is for a 64-bit AAX plugin.
I am not using the new AudioProcessorParameter / APVTS classes and am using setParameter/getParameter. (I’m wondering if it is even be possible to switch to these while still keeping backwards compatibility with old versions from several years ago)
I already had to set various JUCE flags to make sure the plugin remains compatible with older versions (VST and AU, but also with Pro Tools 10 projects that still had the old RTAS version of my plugin for which I wanted to have the AAX automatically replace the RTAS version while keeping all plugin state and automation correct):

JucePlugin_AAXDisableAudioSuite=0
JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE=1
JUCE_FORCE_USE_LEGACY_PARAM_IDS=1
JucePlugin_VSTChunkStructureVersion=0x0000006f

(and I overrode getAAXPluginIDForMainBusConfig to return IDs compatible with older RTAS version)

What is the exact reason the AAX version of my plugin fails the AAX validator? Is there anything I could/should do to change/limit these “number_of_steps”? And if I do so, will this also affect the VST2 / AU version of the plugin (or mess up old RTAS settings which were saved with a plugin version built with Juce back in 2013)?

Any help/advice appreciated.
Of maybe I should just ignore this issue (as Pro Tools seems to run the plugin just fine)?

[this is with the Juce 5.4.1 tagged version of 12 Nov. 2018]

Edit:
When stepping into the code while running in Pro Tools, I can verify that the parameters are being set as AAX_eParameterType_Continuous (because parameterNumSteps > 1000), and the reported number of steps is indeed obtained via LegacyAudioParameter which calls AudioProcessor::getDefaultNumParameterSteps, which is indeed 0x7fffffff (the number reported by the AAX validator). So, I think the code seems to do the expected thing, but there must be a reason the AAX validator reports an error…


#2

@ed95 / @fabian / @rmajors Sorry to bother, but do you guys have an idea about what could be causing this? Or if it is normal/expected perhaps?


#3

I’m not sure why the validator is failing on this, but I’m not too familiar with AAX so maybe someone who is could comment. From looking at the code though I can’t see why this would be an issue, the AAX wrapper is calling through to AudioProcessor::getDefaultNumParameterSteps() in the GetParameterNumberofSteps() AAX callback and storing the result in an int32 and, like you say, 0x7fffffff is within the range. Unless there is a limit for the number of steps in AAX plug-ins, but I can’t see that mentioned in the docs anywhere.


#4

Put a breakpoint in the AAX wrapper in addAudioProcessorParameters() at

auto parameterNumSteps = juceParam->getNumSteps();

how many steps is the value? Which overload of getNumSteps() is being called? If it’s the default (which it looks like) you need to override getDefaultNumParameterSteps() in your processor class and use the slider’s range and resolution to calculate the correct number of steps to return for your parameters. The RangedAudioParameter::getNumSteps() should be a good guide for you.

Booleans (switches) obviously have a step value of 2.

There are some enumerations which define the default step values…

Look for eParameterDefaultNumStepsContinuous in the docs.

Rail


#5

@ed95 That’s also what I was thinking, and I couldn’t find a limit. But I did some further testing by modifying that value and it turns out that the highest value that still passes the AAX validator is 2048 (with 2049 and above it fails; and values below 1000 were no good, as then my parameters are set as discrete, due to JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE=1).

@Rail_Jon_Rogut Yes, as explained in the edit I made to my post, it’s the default alright:
screenshot
Overriding getDefaultNumParameterSteps isn’t possible though, as it’s a static method (and when implementing it with the same static signature in my own processor class, it never gets called, as static methods don’t have an entry in the vtable).
However, I could override the virtual int getParameterNumSteps(int parameterIndex) method and just returning 2048 there for all indices made the plugin pass (I could fine-tune for my “checkbox button type” parameters, but see below…)

So, as with most of these finicky things, I’m now wondering about the effects of making this “number of steps” change for my parameters on the existing projects of my users:

  • does this affect stored plugin state recall from previous versions?
  • does it affect stored parameter automation?
  • does this only impact old projects which had the RTAS version of my plugin and now use the AAX version, or does it also affect projects using the VST2 and AU version of the plugin?

The range of the parameters is not changing (always been between 0 and 1, and I’m keeping it that way for now, as I think changing that would break all kinds of things esp. automation), it’s only the number of steps…


#6

FYI: Rob Majors of AVID answered my question about this on the AAX developer forum: https://dev.avid.com/MP_DeveloperForumSupport?filterId=a9T310000004FCnEAM#!/feedtype=SINGLE_QUESTION_DETAIL&dc=Developer_Community_Q_A&criteria=ALLQUESTIONS&id=9065A000000oScuQAE


#7

Hi,

I also ran into this issue a while ago. The answer I got from Rob Majors back then was that this is to account for control surface rotary encoders which may only change the parameter value by one or a few steps per rotation “tick”.

So I derived AudioParameterFloat and reimplemented getNumSteps().

/**
 * Overriden from AudioParameterFloat. The base class implementation just calls AudioProcessor::getDefaultNumParameterSteps() which
 * returns 0x7fffffff. This results in a "Number of parameter steps exceeds limit" Error when analyzing the Plugin with Avid's
 * AAX-Validator tool DSH. 
 * @return	The number of steps this parameter has between 0.0f and 1.0f.
 */
int CAudioParameterFloat::getNumSteps() const
{ 
	return 0x7ff; 
}