I certainly appreciate the attention to AAX over the last few days. The current tip (Jan 15) seems that it might have busted something. My last build was with the tip of around Jan 11. It worked nicely in Protools 10.3 and a certain not-to-be-named 64-bit AAX host. Between then and now, something seems to have broken. I can no longer load the plugin in either platform, getting the generic message that the plugin may be corrupted or something (I’m paraphrasing).
Have any of you other developers on the bleeding edge run into this?
Are you running the 1.5, 1.0.6 or 1.0.5 SDK?
When a plug-in exists both in RTAS and AAX format, some of their internal ids should match so that Pro Tools knows that, when loading a session, it should load the AAX plug-in with that id and, if missing, search for the RTAS plug-in with the same id.
This rule was not followed in the AAX wrapper until this commit: https://github.com/julianstorer/JUCE/commit/4a9003158a63d035bbaab717ed5ead596a20494c
The result is that, if you had some session saved with an AAX plug-in inside, once you pull this new change and recompile your plug-in with it your plug-in ids will change and Pro Tools will not reload them even if the plug-in has the same name. You should reload the plug-in in the insert where Pro Tools says it is missing, re-save the session and everything will be fine
I’m using the 1.5.0 SDK for AAX (just checked the developer site and it’s still the newest). I found that even a fresh load of PT–with no instantiations of the plugs–wouldn’t load a new one. It’s pre-dawn at the moment, so I’ll get some coffee and give it another shot in a bit.
Well,it looks like one more build (and one more cup of coffee) were all I needed. Working fine now. Thanks!