[fixed] AAX plugins created with 4.2 no longer loadable in ProTools development build

The aax plugins I built with 4.2 are no longer loadable in the ProTools development build, latest 12.4-3Pdev. I tried also wrapped and unwrapped, see this conversation linked below.

It also happens with an empty new created plugin.

I tried also entering the apple sign id into the project, that didn’t help.

Did anybody load a plugin created with 4.2 successfully into ProTools development build?

Thanks for helping…

– Continuing the discussion from Loading .jucer created in Introjucer into Projucer 4.2


It’s on a Mac, right? This could be an issue with paths. Unfortunately I cannot test it myself right now because I do not have an iLok with a PTdev licence available. But here’s a guess: the way the Xcode projects now generated by the Projucer now work is that after compiling the AAX plug-in, they move it to
/Library/Application Support/Avid/Audio/Plug-Ins/
I am suspecting that this is not where PTdev expects them to be. I think it’s the location for the signed non-dev PT one. Maybe you can try manually moving it to the right path for PTdev and then tell me what path that is? I could fix it then.

Just chiming in here, the path should be correct for PTdev as well, at least it was with the old Introjucer generated projects, the only other directory is …/Avid/Audio/Plugins(Unused) IIRC, the folder where unsigned plugins end up when they fail the validation in standard PT

I believe it was only up to PT10 that the dev build loaded plug-ins from a different folder. Starting with 11, the PT dev build loads from the same folder as the non-dev. The only difference is that it doesn’t enforce plug-in signing (although it warns if it loads an unsigned plug-in)

Hi @Timur,
thanks for checking. ProTools (dev and productive) first check, if there is a Plug-Ins folder next to the binary (i.e. ProTools.app bundle) and use that one. If there is none, it uses the default that you wrote correctly.
So the actual path doesn’t matter, I put my executable in that folder that the post build script before 4.2 had hardcoded /Applications/ProTools_3PDev/Plug-Ins so I doubt it’s a path problem.

I also disabled the local Plug-Ins folder by renaming, so PT uses the default folder. I can verify that, because I see all my other plugins, which are not present in the local folder.

So do you have anybody at ROLI, who can test if 4.2 created plugins are still loadable?

Thanks for your time…

I’ll try to get hold of an iLok with a PT dev licence as soon as I can. Please excuse the delay!

In the meantime, if anyone has any more hints about what is going wrong there, please post here.

You can (and should) have your PT Dev in a separate folder – in that folder should be your Plug-Ins folder (and any options files you may require). This will keep your dev plugins separate from your main release PT build.

On my system it’s ~/Applications/Pro Tools Dev/


…that’s exactly how I do it, but the projects created with juce 4.2 build directly into /Library/Application Support/AVID/Audio/Plug-Ins, which I also think is a bad idea, because the unsigned plugins there aren’t usable anyway in released PT, as I said before…

The location the previous post build script did, was the preferable way: build into a private Plug-Ins folder next to the development PT and and after testing wrap it into the /Library/.../ folder to check with released PT…

Previously we had a Post-Build script we could edit to put the plugins anywhere we preferred.

It would be nice to still have that ability – at the least a place to define the destinations in ProJucer.


1 Like

OK, so I could add per-configuration build settings “AAX Install path”, “VST install path” and so forth, for the Xcode exporter. Would that work for you? I think also it’d be a bit cleaner than the post-build script approach.

But it seems that doesn’t help with the issue that the AAX doesn’t load. I still don’t have an iLok unfortunately… :frowning:

Would work for me, but as you say, it’s not the actual matter here…
hope you get the ilok soon… and keep it, would love if you could add aax to the recurring testing routine… :wink:

1 Like

I have JUCE4.2 AAX 64 builds working on mac and windows.

However - I’m also using the old method (adding the wrappers directly, compiling a polymorphic plug, and then using a post-build script to deploy).

Trying it now with the newer method.

@AaronLeese Great, thanks for checking. How do you use the polymorphic build? Simply use an old XCode project and don’t click “Save jucer and open in IDE”?
I avoided that, because last time I upgraded and didn’t recreate the project was the source of problems…

Well, basically just include the wrappers directly it seems.

Right, silly me, I never looked into the “JuceLibrary"Code” on how the main entry is done, I just implemented the Processor class and go…
I should read a litte into it, but I hope it will not be necessary and things work again like they did before…
But good to know, that there is an option, if all else fails…

Ok - the new example plugin doesn’t seem to build a proper AAX.

I’m not really sure why, but after adding an aax target, and changing all the needed stuff, plus reviewing the AppConfig.h file … I get what seems to be an aaxplugin, but …

NOTE this is not a dialog telling us that the file isn’t digitally signed (that comes up later).

So … I have no idea what this (completely useless) popup from pro tool is trying to tell us, but clearly something is wrong with the plugin.

My guess is that ProTools doesn’t like the /Contents/frameworks directory that is being put in the plugin. It seems if I replace the actual MacOs/JuceDemoPlugin with another (all inclusive) executable, then it loads properly.

1 Like

Thanks for the verification. Feels good that it isn’t only happening to me…

That’s odd, the framework thing should not break anything.
Please be patient, we consider this a top priority bug and will fix it as soon as we can.

Awesome! I’m sure you’ll figure it out soon enough.

Some of the folks on this forum use the Avid provided debug tools too … which could probably shed light on this, if any of them have a minute to test and chime in.

Yeah it would be great if someone with a proper PT development setup would try to debug this and post any insights (while we figure out how to resolve our iLok/licence situation).