JUCE and macOS 11 / ARM

[DavidCNAntonia]

@graeme-2

Wondering if anyone’s seen this

I found this and had to put set my signing ID in the xcode exporter settings in projucer. Works fine now for testing.

[graeme-2]

Thanks, that indeed seems to fix it! I’m using cmake so I used the instructions in the CMake api doc to add the code sign identity and development team. I couldn’t figure out how to apply them to the DemoRunner but I followed the instructions for building the basic GUI app and that worked.

I must say it’s still strange that changing these settings in Xcode isn’t enough. And it’s also strange that creating a project in Xcode (and downloading one from apple’s dev site) happily profile without the need for this. My guess would be that there’s something configured wrong in the JUCE generated projects. Or maybe Apple is giving preferential abilities for it’s own project files or something? That’s probably far-fetched but who knows.

[graeme-2]

I double checked on my other machine using the same test setup (Cmake GuiApp example) and confirmed that the signing information is not required for profiling with that setup.

Machine 1 (no signing required) : intel, Catelina 10.15.6, Xcode 12.1
Machine 2 (signing required): m1, Big Sur 11.0.1, Xcode 12.2

Both machines used current JUCE master with CMake 3.19.1

[graeme-2]

I’ve now discovered that changing anything in the project file from within Xcode will cause Instruments to stop showing the symbols again. Between this and swift projects not requiring signing I think I’ll chalk this all up to bugs in Xcode.

[thetechnobear]

@ graeme-2 how did you get cmake to with juce ?

Im having issues with juceadie compiling, it appears to be assuming mac are intel?

Cmake build failing on bigsur / apple silicon

juceaide is failing to build on mac mini m1 / BigSur 11.0.1 Im trying to build native (arm) juce vst3 plugins using cmake. (my other non-juce projects are compiling quite happily with cmake/native… just issues with juce) -- Building juceaide CMake Error at juce/extras/Build/juceaide/CMakeLists.txt:86 (message): Failed to build juceaide just taking one of the build errors, we can see its failing on the asm(“int $3”) my assumption is, juce is assuming MAC == INTEL #elif JUCE_GCC || JUCE_MAC…

Ive got cmake (from homebrew) building my other cmake native projects successfully… but juce is throwing errors.

---

FIXED: needed to pull new version of juce - thanks @reuk for the info

[thetechnobear]

another small issue…

I created universal binaries for vst2 and vst3.
both show up in AudioPluginHost without issue.

however, Intel hosts specically Ableton Live 11 (beta)/Bitwig 3.3 , only the vst3 shows up. neither show the VST2 … if I do file on the vst2, it shows both the arm and x86 build.

note: this is using cmake, but not sure if this is relevant or not.

[ericsen]

Has anyone been able to profile an ARM release build and see per line performance metrics in your source code? I have set up my signing ID in projucer, disabled Strip Local Symbols, and added the suggested Xcode flags, but when profiling via Instruments I’m only able to see the machine code, not the C++.

@DavidCNAntonia, @graeme-2 - does this work for you?

[graeme-2]

Hi ericsen. Sorry, I ended up returning the M1 so I don’t know anything more about the issue.

[modosc]

@ericsen

Has anyone been able to profile an ARM release build and see per line performance metrics in your source code? I have set up my signing ID in projucer, disabled Strip Local Symbols, and added the suggested Xcode flags, but when profiling via Instruments I’m only able to see the machine code, not the C++.

i don’t have an ARM but i’ve noticed that on my (intel) mac when i select “profile” from xcode the first run never has symbols. i have to stop it in instruments, go back to xcode, then “profile without building”, then i get symbols.

[ericsen]

Thanks, but the “Profile without building” is greyed out here. I am getting symbols though, I’m just not able to dig into the source code too see exactly where bottlenecks might be. However, it seems it’s not ARM specific. I am able to do this in Visual Studio and on my older Mac/Xcode, but on BigSur/Xcode12 I can’t get it to show on neither Intel or Apple Silicon builds.

As I’m barely one level above moron I might be missing something obvious, but I’m wondering if anyone is able to get “per line” profiling to work on BigSur/Xcode12?

[apple412]

Would you elaborate on the lines you added to patch the AAX SDK? Could you post a git gist somewhere?

[mcmartin]

On May 19th, Avid made an announcement titled “Compiling AAX SDK 2.3.2 for Apple Silicon” on their developer forum.
You can also find a link to that announcement/article from the Avid Developer Newsletter 127.

[mucoder]

I’m still a bit confused about arm64 vs arm64e architectures: which one is needed for a plugin or app to run on apple silicon macs? I read that apple’s own binaries use arm64e ?

[ttg]

arm64.

arm64e is still ONLY for kernel related code and requires extra signing from Apple. It might be changed in the future but that’s the state at least with macOS 11 and 12 with M1 chips.

[Verbonaut]

It looks like Apple intends for it to be more widely used than just things in the kernel. What limits us using it now?

https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication

[ttg]

Mind the -

Test your app against the arm64e architecture to ensure that it works seamlessly with enhanced security features.

You should also prepare for deprecating AUv2, OpenGL and more.

Currently for plug-ins (and apps) - arm64 is the most compatible and recommended.

So it’s indeed important to test and evaluate ahead (similar to getting a DTK to get yourself ready when it’ll be the recommended)