Pro Tools I/O allowed I/O for plugin changed in 2024.10

General JUCE discussion
1

I cannot figure out why this is happening but i have a multichannel plugin that has several i/o configurations for when the host is Pro Tools (ultimate/hd), since updating the developer build to 2024.10 (users were reporting this issue) most of the previously allowed configurations do not list at all. On top of this when checking the expected configurations via isBusesLayoutSupported the configs that used to work and now do not list all return true and are accepted.

nothign has changed except updating the version of Pro Tools i open the product AAX plugin, i am really stumped at what else to do, has some breaking change been introduced?

2

Are you manually checking the plugin host type in order to decide which configurations to hide/show? If so, this might be the source of the problems. Recent versions of Pro Tools use a separate program to scan and validate plugins, including detecting valid channel layouts. Therefore, if a particular channel layout is not detected by this scanner tool, then Pro Tools itself won’t display that layout either.

After making changes to your channel layout code to work around this issue, you might need to reset the channel layout information generated by the plugin scanner tool, so that Pro Tools will re-scan the plugin on next launch. On macOS, you can remove the files at /Users/Shared/Pro Tools/AAXPlugInCache, and on Windows the files are stored at C:\Users\Public\Pro Tools\AAXPlugInCache.

3

thats gotta be it! I am using:

juce::PluginHostType hostType
if (hostType.isProTools())
    // I/O for PT

ok so is there a way to extend this if statement or should i just use AAX compiler macro instead?

thank you so much for this callout, i had no idea and really could not find any intel on this, it really felt like there was some weird process caching that i had not way to interface with…

4

the annoying thing is the macro complicates my build pipeline because i would have to separate AAX cmake configurations from the rest…

do you know if I can capture this in the runtime if statement i have above in any way? can we include Pro Tools service/app for scanning plugins as also true from the juce::PluginHostType.isProTools() ?

5

AudioProcessor has a data member wrapperType that will be set to wrapperType_AAX when running as an AAX plugin.

6

duh! thanks!

7

I just hit the same issue. Honestly, one would really expect isProTools() to be true for scanning in Pro Tools as well. I think the implementation of isProTools should really just be AudioProcessor::getPluginLoadedAs() == AudioProcessor::wrapperType_AAX or at least a comment in the documentation mentioning this issue.

1 Like
8

Avid Media Composer can also load AAX plugins. So being AAX doesn’t guarantee the host to be Pro Tools.

2 Likes
9

OK another option is to check which macOS bundle the executable file is located in. Both the pluginrunner (Pro Tool’s scanning executable) and Pro Tools itself is inside the Pro Tools.app bundle.

10

id prefer this, id expect isProTools to return true for both ProTools (any version) and the “pluginrunner” for ProTools

11

See the Heads Up I posted here last August:

Rail

1 Like