We’d like to add M1 Native support to our plugins, but since the AAX SDK does not support that yet, we’re wondering if there is some way to create exporters for AAX that differ from those for VST3 and AU? As it is now, it looks like we’d have to use separate .jucer files, one for AAX to build without M1 Native support, and one to build VST3 and AU with it. That’s not ideal, and means we have to do twice the work any time we make a change to the .jucer file(s). What are you guys doing for M1 Native support? Ignoring it doesn’t seem wise at this point.
We opted to create a second Xcode exporter with its target project folder set to something other than the default. This kind of sucks, and you have to keep a close eye out when opening your project folders, and picking your target in Xcode… so it’ll get annoying pretty quickly.
We also set the architecture at the exporter’s root to be sure it was set up correctly at the project levels.
Here’s what we did for our main desktop Xcode exporter:
For each subsequent configuration, we set this explicitly:
And for our Xcode M1 exporter:
We left the configuration’s architecture to Default.
1 Like
Hey, since I’m under NDA with Avid I am not sure how much I can share so I’ll err on the side of caution (seems like you’ve got an Avid dev license too), but I can say that you should check out the latest AAX beta SDK, as once that goes from beta to release it’ll make this issue in the jucer redundant.
This is intriguing, but I’m not understanding how you stop the AAX plugin being built for the M1 exporter?
My hacky way of doing it was to have my build script do some sed-fu to create separate .jucer files, one which targets x86_64 only and builds just the AAX and another that makes fat binaries but excludes AAX.
The sooner ProTools runs natively on M1 the better!
You can call xcodebuild with the -arch parameter to override the architecture and the -target parameter to build only one plugin variant. So once the default Xcode exporter from your .jucer file generated your .xcodeproj, you can do multiple xcodebuild calls in order to build all your plugin variants, with the exception of the AAX version being built only for x86_64. Something like this:
xcodebuild -project your.xcodeproj -configuration "Release" -target "ProductName - AAX" -arch x86_64
xcodebuild -project your.xcodeproj -configuration "Release" -target "ProductName - AU"
xcodebuild -project your.xcodeproj -configuration "Release" -target "ProductName - VST3"
2 Likes
Just change Architectures to x86_64, only for the AAX plug-in target in Xcode (manually). That was the only thing I had to change to make it work.
That doesn’t help with an automated build system, though.
But how do you deal with the Shared target, upon which the actual plugin targets are built?
As far as I can remember, I never had to deal with the shared code target. I’ll have a look tomorrow but I suppose it is considered as a build dependency of the other targets so it’s probably handled automatically, unless I’ve been lucky not to have any issue because I built the AAX target at the end and the shared code target was already built for all architectures?
It’s a separate target, which builds a library that the other targets then use. So you’d have to build it first, I think. But if you build it with arm support, would the AAX target be able to link it in? Haven’t tried, but seems problematic to me.
I confirm the Shared Code target is a build dependency of other targets so there’s no need to explicitly build it yourself.
So no matter which target/architecture combo you want to build, it’ll just work. First make universal plugins (arm/x86_64), like VST3, AU, etc:
xcodebuild -project your.xcodeproj -configuration "Release" -target "ProductName - VST3"
xcodebuild -project your.xcodeproj -configuration "Release" -target "ProductName - AU"
Then make the AAX plugin for x86_64 only:
xcodebuild -project your.xcodeproj -configuration "Release" -target "ProductName - AAX" -arch x86_64
Making a Universal Binary is almost like concatenating the x86_64 and arm64 binaries together into a new file, especially for static libraries, which are technically just a collection of object files.
When linking the AAX plugin for x86_64, the linker will ignore the arm64 symbols from the shared code static library. It will also ignore all the x86_64 symbols that your plugin doesn’t use/need. There shouldn’t be any problem.
1 Like