Now that I enabled AAX builds for my plugin in the Projucer, it looks like I get 2 different MyPlugin.aaxplugin “bundles” on Windows.
I get this structure:
Visual Studio 2015
| | \---MyPlugin.aaxplugin
| | \---Contents
| | +---Resources
| | +---Win32
| | \---MyPlugin.aaxplugin
| | \---x64
| +---Shared Code
However, when I look at some AAX plugins coming with ProTools, I can see that there are plugins that have a (different) .dll in both the Win32 and x64 subfolders under Contents.
Should the Projucer bundle the 32-bit and 64-bit versions into one .aaxplugin bundle and is something going wrong here for me? Or am I expected to do this “merge” myself?
On another note, I also found on this page ( http://avid.force.com/pkb/articles/en_US/FAQ/pro-tools-plugins-folder-location ) that there are in fact 2 install locations for AAX plugins on Windows:
- C:\Program Files\Common Files\Avid\Audio\Plug-Ins for 64-bit
- C:\Program Files (x86)\Common Files\Avid\Audio\Plug-Ins for 32-bit
So, the other option seems to be to just keep 2 different .aaxplugin bundles and install them in different folders… (I’m guessing the only reason why there are both a Win32 and x64 subfolder under Contents is so you can just copy the same bundle to both locations)
So: should Projucer create a single bundle with 32-bit and 64-bit .dlls? And if not, should I do it myself, or what is the normal thing to do here?
Any advice welcome!
What version of Pro Tools are you targeting? It’s my understanding that the most recent versions only support 64-bit plugins anyway?
Yes, that’s right:
- ProTools 11 and up only support 64-bit AAX plugins
- ProTools 10 was the last version to support RTAS + it also supports 32-bit AAX
I dropped RTAS support, but since building 32-bit AAX seems to go quite smoothly, I am considering adding 32-bit AAX as well so that people stuck on ProTools 10 are also supported. Well, at least on Windows, still need to see how it goes on Mac.
Does Pro Tools 10 have a 64-bit version?
I’d be interested to know what the proportion of Pro Tools users was using the 32-bit version if there’s a 64-bit alternative. (It’s probably quite high if the transition to 64-bit is slow on Windows actually).
No, ProTools 10 is AAX 32-bit only (and RTAS of course, which is 32-bit).
I guess the real answer to your question is where does Pro Tools 10 look for plugins then?
If it’s only the x86 dir then you probably need to create two separate bundles.
Pro Tools 10 on windows looks in the Program Files (x86) path while Pro Tools 11+ looks in Program Files… so if you’re installing you need to install to both locations. You only need to create a single bundle though with the win32 and the x64 .aaxplugin in their respective folders.
Yes, that’s what I first thought: one bundle, and you can copy it to the 2 different folders.
But then I saw that the Projucer creates 2 separate bundles, and wondered if that was correct and it’s just not working perhaps. Maybe @ed95 or @fabian can comment on this?
It’s worth noting that with Eden 4, there is no ability to sign 32-bit AAX plugs on Windows; you can only do 32-bit AAX with “real” iLok protection, to the best of my knowledge. Someone can double-check my math on that, but if you can’t sign it, there’s no real point in building it, I don’t think.
@crandall1 Strange: I did sign my 32-bit AAX dll just fine this afternoon.
I haven’t run it in ProTools10 yet, but since you mentioned this, I just did a verification of the signature for the 32-bit dll with the wrapping tool (latest version 4), and it says it’s signed properly (“the digital signature was verified”, some info, and “The binary was signed but not wrapped”).
We sign and fusion protect our x64 and Win32 aaxplugins.
Heh. I misread the release notes. I took this paragraph…
“As of Eden 4.0.0, the Eden SDK for Windows requires a 64 bit operating system. We no longer provide Eden SDK installers for 32 bit operating systems.”
…far more literally than intended, it seems. My mistake. Nothing to see here. In any event, we release 64-bit only AAX, and nobody has ever written to ask for 32-bit, so shrug