AAX codesigning


I’m trying to build an AAX plugin and I’m unsure about the signing process.
There already is a lot of pace stuff inside the JUCE compiled AAX. Is it already signed when compiling with JUCE or do I have to get in contact with PACE?
I can’t really test the plugin in Pro Tools since that is not running on Catalina so far.


JUCE will only take care of building, the signing step is completely separate.

You have to get in touch with PACE. They will provide you with their bespoke signing tool (wraptool), and it will use your certificate to sign (either the Apple Dev cert or any certificate, that is accepted by their/ProTools CA.

For development, AVID provides a debug build, that allows to run unsigned plugins, if you are in the development programme.

I am just telling the common knowledge, the details might be covered under NDA, so sorry for not answering in more detail.

1 Like

Ok, thanks for the info. I contacted PACE.

The problem is, that our plugin won’t load and I’m afraid it’s because I need to package a bunch of dylibs into the plugin (at least that’s what I’m doing with AU and VST). Can anybody elaborate on what the __Pace_Eden.bundle and _CodeSignature folder are doing? Am I invalidating the plugin by copying stuff into it?

You’ll break the signature of the bundle by changing its contents after it’s been signed. Signing has to be the last thing you do.

Yes I know. What I am unclear about is if the existsing signature has any influence when using the development build. Like Daniel said, I thought I need to do the PACE signing separately. But obviously some signing is already done by JUCE. I’m wondering if these are two separate signing steps and if the signing done by the JUCE build is integral also for the dev build of Pro Tools.

Either way does anybody know any methods of debugging AAX loading issues? I’m not sure this is acutally a problem with signing. All I get is “the plugin failed to load because it is not a valid 64-bit AAX plugin” and I don’t know exactly where the problem is.

You can only have a single _CodeSignature. The PACE sign tool completely replace any existing signature. This is quite a typical thing to do as anyway Xcode 11 will always sign binaries.

If you’re not signing with the Pace SDK then you won’t be able to load an AAX plugin unless you use a development build of Pro Tools. That would be the place to start if you have loading issues as it takes signing out of the equation.

I don’t see why you have an existing signature, by default an XCode project you export with Juce doesn’t get signed at all.

Edit: I’m not using XCode 11, so perhaps that’s new.

Dumb error on my side.
I just found out, that a plugin with the same name as ours already exists by default in pro tools. And JUCE overwrote parts of that bundle with our plugin but left the signature of the other plugin in there.

1 Like