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

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

The AAX wrapper isn’t compiled at all on OSX. There’s a define JUCE_INCLUDED_AAX_IN_MM right on top of the AAX wrapper which isn’t set anywhere (I don’t really get why it’s in there, but anyway…). If you set JUCE_INCLUDED_AAX_IN_MM=1 in XCode’s preferences, the plugin is recognized and loaded in the developer version of Pro Tools.

Edit: Code signing works as well… first you need to sign the framework in the AAX bundle using codesign, then sign the AAX plugin as usual.

Actually, #define JUCE_INCLUDED_AAX_IN_MM 1 should be in juce_audio_plugin_client_AAX.mm, which is now the file that includes juce_AAX_Wrapper.cpp (it used to be juce_AAX_Wrapper.mm which also has that define in it, but no longer gets compiled).

Aha! There we go … thanks @siedschl !

OK guys, I have pushed the fix, could you please update to the newest JUCE tip and confirm that AAX works fine on OS X now? Thanks!

Loading into the development build works now again. I’m about to check the dongle stuff…

EDIT: signing works as well, I can create AAX plugins with 4.2 and load them into development and released ProTools.

Thanks everybody, siedschl, Aaron and Timur, great teamwork!

@Timur can you please add the TARGET_DIR / install path as you proposed?

Yep… I need to fix one other critical bug first, and then this task is next on my to do list :slight_smile:

sounds good, thanks

Well, the conversation has gone on a bit, but just want to say that I like this idea.

I have now implemented this, please update to the newest tip!

You will find these new Projucer build settings. Grey means it’s using the default setting - you can however override it per configuration (debug/release).

Enjoy. Hope this makes working wth JUCE 4.2 easier.


Sweet!!! :grinning:

Yeah great, thanks! That’s so much better now, I can remove the symlink and don’t have to load all plugins each time :slight_smile:

Since Pro Tools 10 (which means for all AAX), the correct install location for OSX plug-ins is
/Library/Application Support/Avid/Audio/Plug-Ins
/Library/Application Support/Digidesign/Plug-Ins

See Avid developer forum post AAX plug-in install directories (registration required)

And if you are using a PT10 developer version you’ll also need to copy it to
in order for it to show up there. Which means if you have PT10 dev co-installed with PT 10 release or PT 11 or 12, you’ll need to deploy the binary to multiple locations, perhaps with a post-build script.

Yeah the paths were mixed up, but I already fixed it yesterday:

And now you can specify a different binary location for Debug and Release respectively, so you could use the ProTools_3PDev one for Debug if you’re still on PT10.

Also, yes, just like you say, you can add a post-build script to copy that binary to as many additional locations as you want. So I think it’s all fine now, no? :slight_smile:

Should this feature support relative paths? When I add leading …/…/'s, I end up with an error in Xcode, which strips all ascenders and tries to place the binary at root /

Yes currently this only supports absolute paths. We are currently re-working some of this code which should fix this as well.

1 Like