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.
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).
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).
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
Not /Library/Application Support/Digidesign/Plug-Ins
And if you are using a PT10 developer version you’ll also need to copy it to /Applications/ProTools_3PDev/Plug-Ins
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?
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 /