Transition from 4.1.0 to 4.3.1 and AAX I/O issue

[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.