Transition from 4.1.0 to 4.3.1 and AAX I/O issue

[bld]

@pflugshaupt

How are people updating JUCE going to realize they need to implement the callback to get backwards compatibility? This is a major problem.

Your customers will tell you

[chkn]

too late, also like JUCE_FORCE_USE_LEGACY_PARAM_IDS
I prefer a solution where the developer has to make an active decision, wether it should use the new or the old layout.

[pflugshaupt]

Not too late… it’s only on develop for now. This kind of problem is the worst if it gets reported by customers. For about two months I had no idea what caused this issue and at the same time it’s an issue that will make customers go nuts. Loading old projects so far hasn’t been part of my testing routine.

I think this is such a potentially annoying issue, builds should just break for updaters unless they implement the callback.

[frankfilipanits]

I’m puzzled why the develop fix introduces its own AAXFormatIndex when there is an existing enum AAX_EStemFormat in the AAX spec, in AAX_Enums.h.

Also, the AAX Param IDs are of type AAX_CTypeID which is defined in AAX.h as uint32_t – why use a signed int32 instead?

These kinds of parallel almost-the-same-but-not-quite reimplementations of things tend to lead to very difficult to debug problems down the road.

[bld]

@chkn

I prefer a solution where the developer has to make an active decision, wether it should use the new or the old layout.

You can simply use old layout IDs with your own getAAXPluginIDForMainBusConfig() returning just the increasing index.

[chkn]

But how do I know, which were my old ids l?

[fr810]

OK. A lot of things to reply to:

@pflugshaupt

“uniqueFormatId = (uniqueFormatId * 16) + aaxFormatIndex” Why limit this to 16 configs? AAX currently has 18 and 2 special ones and you now have 13, but 16 is too close in my opinion. Give it some safety for the future!

OK. This is fixed on develop now!

 

@pflugshaupt

How are people updating JUCE going to realize they need to implement the callback to get backwards compatibility? This is a major problem.

They’ll know because “your customers will tell you”. Seriously, this is similar to the JUCE_FORCE_USE_LEGACY_PARAM_IDS flag: any new JUCE user or any JUCE user developing a new plug-in will not need to override anything. Anybody who has already released an AAX plug-in is likely to test their upgrades and try loading old projects. They are likely to stumble into this problem. I know how frustrating this must be for some but any alternative is really not desirable either (we thought about this for a long time) - let’s not discuss this on this thread though (I’ve created a new forum post here) as it is likely to go completely off topic ;-).

 

@pflugshaupt

Do we really need to dump what old builds were using? Could you provide information how the enumeration worked for 4.1 and 4.3 so we can make this a bit less painful?

The old numeration went through each configuration in order of the JucePlugin_PreferredChannelConfigurations array that you specified in the channel configuration field in the Projucer. The first configuration would get the id 'jcaa'+0, the second 'jcaa'+1 and so on. After JUCE 4.1, we go through all possible stem formats and check if the plug-in supports it. If yes, then the first configuration is assigned the 'jcaa'+0 plug-in id. The second supported configuration will be 'jcaa'+1 and so on. The order in which JUCE probes all possible formats is like this (pseudo code):

 AAX_EStemFormat stemFormats[] = 
 {
    AAX_eStemFormat_Mono,
    AAX_eStemFormat_Stereo,
    AAX_eStemFormat_LCR,
    AAX_eStemFormat_LCRS,
    AAX_eStemFormat_Quad,
    AAX_eStemFormat_5_0,
    AAX_eStemFormat_5_1,
    AAX_eStemFormat_6_0,
    AAX_eStemFormat_6_1,
    AAX_eStemFormat_7_0_SDDS,
    AAX_eStemFormat_7_1_SDDS,
    AAX_eStemFormat_7_0_DTS,
    AAX_eStemFormat_7_1_DTS
 };
 int pluginId = 'jcaa';

 for (AAX_EStemFormat mainBusInputFormat : stemFormats)
     for (AAX_EStemFormat mainBusOutputFormat : stemFormats)
          if (pluginSupportsFormat (mainBusInputFormat, mainBusOutputFormat))
              setAAXPluginID (pluginId++);

 

@frankfilipanits

I’m puzzled why the develop fix introduces its own AAXFormatIndex when there is an existing enum AAX_EStemFormat in the AAX spec, in AAX_Enums.h.

The getAAXPluginIDForMainBusConfig doesn’t care and should not know about AAX stem formats. It goes through the AudioChannelSets that both JUCE and AAX supports and assigns a unique number to them which has nothing to do with the stem formats.

 

@frankfilipanits

Also, the AAX Param IDs are of type AAX_CTypeID which is defined in AAX.h as uint32_t – why use a signed int32 instead?

The plug-in id is not a param id. The plug-in id has the type AAX_CPropertyValue which is int32.

 

@chkn

But how do I know, which were my old ids l?

You’ll need to grab an old version of your code. JUCE has no way to know which order you specified your channel configurations in the Projucer.

[yfede]

Another consideration (maybe pedantic): the official documentation says that the id is:

Four-character osid-style Effect identifier for real-time native audio Effects.

To my eyes this wording implies that it is expected to be composed of ASCII printable characters when considered as a sequence of chars (albeit, I admit, such limitation may not be enforced anywhere inside Pro Tools).

Anyway, to be totally compliant, why not use this slightly different scheme for encoding the id:

• ‘j’ is the first char. always
• ‘c’ is the second char for native ID, ‘y’ for AudioSuite
• third char encodes the input bus format, enumerating among those supported by AAX starting from ‘a’ (and up to ‘z’, making it at least 26 available values instead of the current 16, which addresses the issue raised above by @pflugshaupt )
• fourth char encodes the output bus format in the same way.

[fr810]

Sounds reasonable. I’ve pushed this to develop.

[frankfilipanits]

@fabian

Also, the AAX Param IDs are of type AAX_CTypeID which is defined in AAX.h as uint32_t – why use a signed int32 instead?

The plug-in id is not a param id. The plug-in id has the type AAX_CPropertyValue which is int32.

I misspoke when referring to it as a Param ID (gotta let the coffee sink in before typing). But the plugin IDs are supposed to be AAX_CTypeID - look at all the examples provided with the AAX sdk. And as yfede points out, they are really intended as FourCC (four char code), after the old OSType that was used for RTAS/TDM. These should be unsigned, and preferably map to four printable characters.

[fr810]

@frankfilipanits

they are really intended as FourCC (four char code), after the old OSType that was used for RTAS/TDM

Yes this is already fixed on develop. I’ll change it to unsigned with the next commit. However, the id is eventually used in SetProperty which expects a signed int. So I guess you could argue either way. But you won me over.

[bld]

One thing is wrong here:

@fabian

The old numeration went through each configuration in order of the JucePlugin_PreferredChannelConfigurations array that you specified in the channel configuration field in the Projucer. The first configuration would get the id ‘jcaa’+0, the second ‘jcaa’+1 and so on.

The above is true for Juce < 4.1

@fabian

After JUCE 4.1, we go through all possible stem formats and check if the plug-in supports it. If yes, then the first configuration is assigned the ‘jcaa’+0 plug-in id. The second supported configuration will be ‘jcaa’+1 and so on.

Not true for 4.1 with setPreferredBusArrangement() but is true for 4.3 with isBusesLayoutSupported().
I’m not sure when it was changed in between but as I wrote in the original post in plugin compiled with 4.1 supporting {1,2} and {2,2} they are enumerated that {2,2} is 'jcaa'+0 and {1,2} is 'jcaa'+1.

[pflugshaupt]

Adapting to this new solution I looked at the AAX wrapper source code and I believe I found a bug that might lead to random behaviour with both the old and the new solutions. Maybe this should be a new thread, but it is still half related.

Around line 150 of juce_AAX_Wrapper.cpp the aaxFormat static array is initialized with some AAX constants. In the AAX version I use AAX_eStemFormatNum is 18. And it might go up in the future. However only the first 13 entries are initialized.

Later the code iterates through the array twice to come up with all the possible combinations. Currently this means it goes through 5 garbage values which might randomly be valid stem formats and then bad stuff would happen.

I think the array should never have been initialized with that size, but instead the size should just depend on the used initializers.

Fabian, your pseudo-code above does this more correctly than the actual implementation…

[fr810]

Ahh thanks for the heads up. In fact, I was still compiling with an older AAX SDK where the AAX_eStemFormatNum was still 13. This must have changed recently. I’ve pushed a fix to develop which will be public any moment now.

[fr810]

@bld

Could you also apply it on the master branch?

Re-thinking this, I think this should go on master as we don’t want AAX plug-ins being built with the wrong id.

[bld]

Agree. Maybe better as new version with info in ChangeList.txt than just a merge.

[pflugshaupt]

Still trying to wrap things up here I’m trying to come up with the correct stuff to tell my customers. Am I correct that the weird orders (starting with 2|2 …) were only present in Juce versions 4.1 <= x < 4.2.4 ? Before we were using the configurations list and afterwards it would just go from 1–x on ins/outs (which at least in my case should be compatible to the manual configuration list). Bascially I’m trying to figure out what time period/juce versions correspond to the no longer used “setPreferredBusArrangement(…)” which is when my plugins reported incorrect aax ids.

[fr810]

I guess the best thing to do is to checkout the commit that you released your product with. And then check which ids corresponded to which layout. That’s the only way to be 100% sure.

[bld]

If it helps you, in my case on 4.1 for the default AudioProcessor::setPreferredBusArrangement() it assigns the pluginIDs exactly as Fabian described with the pseudo-code with the exception that available stemFormats are different:

AAX_EStemFormat stemFormats[] = 
{
    AAX_eStemFormat_Stereo, 
    AAX_eStemFormat_Mono,   
    AAX_eStemFormat_LCR,    
    AAX_eStemFormat_Quad,   
    AAX_eStemFormat_5_0,    
    AAX_eStemFormat_7_0_DTS,
    AAX_eStemFormat_7_1_DTS,
    AAX_eStemFormat_5_1   
}

That’s why for my plugin {2,2} goes first and {1,2} second.

[pflugshaupt]

thanks for the code. I’m trying to find this in the JUCE git commits, but I am having difficulties. Maybe I’m not using the right tools. Does anyone know a git trick to find the time period the above code was part of JUCE? I’m usually using the GitHub Client, but it can’t do that at all. XCode can show earlier file versions, but that means I have to go through commits one by one. I wish I was a git wizard, but I’m not.

Well actually I think I’ll just create a test project and go through all my released updates to see when it breaks.