Anyone aware of a breaking change which happened in either the AAX SDK or JUCE AAX wrappers.
While debugging why some parameters were not showing in the parameter panel in protools, I stumbled upon this:
typedef const char * AAX_CParamID; //!< Parameter identifier \note While this is a string, it must be less than 32 characters in length. (strlen of 31 or less)
It appears JUCE is silently truncating paramIDs > 31 when supplying them to protools, when protools goes to retrieve these parameters, they don’t exist within your plugins.
The curious thing is this seems like a new bug. Anyone have insight into this? Is there a way to safely truncate the paramIDs which are longer than 31 chars when sending them to AAX?
Truncating them won’t help if there are then duplicates because you’re removed the portion that differs. Better to rename them to use shorter names. Odd that this ever worked with longer names. The AAX SDK has always had that limit, hasn’t it?
Yeah I think somehow JUCE didn’t have this issue before though cause I’ve done other projects on older JUCE versions where the IDs exceeded those lengths and still worked in AAX… ohh well looking forward not backwards but still it seems it shouldn’t silently fail like this in JUCE.
It must be a legacy param vs new param style thing
Thanks for raising this. I had a go with 5.4.7 and saw the same behaviour, so I don’t think this has changed recently, if at all. I’ve added some jassert checks which should help to prevent this sort of issue in the future, although of course this will only have an effect when running a JUCE AAX plugin under a debugger. I’ll update this post once the changes are on develop.
I noticed that the AAX SDK already has some built-in assertions that warn about truncated param IDs. To view these assertions, you can search for AAX_ASSERT in the Pro Tools log files. On my copy of Pro Tools 2020.9, I had to enable log output in “Setup → Preferences… → Operation → Save Logs…”, and I could then view the logging output in /Applications/Logs. It’s probably a good idea to get into the habit of scanning these log files periodically when testing AAX plugins, as they can provide useful diagnostic output without needing to attach a debugger.
I realized the reason why some older plugins worked was because of an older bug in a specific JUCE version which was still resorting to int param IDs even if strings were provided. That was fixed but unfortunately left some buggies around for any plugins which went out with that JUCE version.
One note @reuk – I would suggest the assertion to be global and steer users away from IDs which won’t be supported in some DAWs. AAX comes after launch for a lot of indie devs, at which point it’s too late to fix the problem in a clean manner
I’ve added some extra parameter ID checks on develop now. These can be disabled with a preprocessor definition if they’re too noisy in existing projects.
