Apple Silicon (m1) support
Opened this issue · 12 comments
Unable to find this question on issues, so...
Are you planing native apple m1 builds?
Is your feature request related to a problem? Please describe.
Odin can run through Rosetta 2, and it's even usable, till you try to pick preset - it will hang (Reaper + Odin II vst3).
Describe the solution you'd like
Universal binary for apple m1 SoC!
Hi @oiwn, M1 builds are currently not planned from my side.
However, the code is open source. I'm not too familiar with M1, but creating such a build could be as easy as recompiling on / for the target architecture. Perhaps a community member would be able to tend to it.
Looks like used version of JUCE (6.0.8) support m1 arm already.
Improved assertion behaviour on macOS ARM
I'll try to build it by myself.
@oiwn Any luck? Also tried it but I am always getting the following error.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/mmintrin.h:33:5: Use of undeclared identifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?
I already tried to add -DJUCE_USE_SSE_INTRINSICS=0 to cflags without any luck ..
@oiwn Any luck? Also tried it but I am always getting the following error.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/mmintrin.h:33:5: Use of undeclared identifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?I already tried to add
-DJUCE_USE_SSE_INTRINSICS=0to cflags without any luck ..
same, I'll try again at weekend.
I just tried to compile another JUCE project in the cloud with an x64 image and hit the same problem. I think the problem isn't with M1 but with something that changed from MacOs 10.14 to 10.15 and consequently BigSur. I'll see if I can resolve the situation.
just poking around here a wee bit - i wanted another Juce synth to try some clap.
M1.patch.zip
here's a patch which makes it build on M1 no problem
I have this mixed up with a cmake port but can separate it as a PR if you want.
Hi @baconpaul,
Thanks for your input! I just took a look at the whole situation. It seems the ScopedNoDenormals class is entirely legacy code. By now ScopedNoDenormals are integrated into JUCE and that's the class that really should be used. I pushed an according commit to the devel branch. Sorry, I hope you didn't invest too much time into the fix?
In the meantime, I have a few questions from an absolute M1 noob:
- M1 builds are the
amd64target in Projucer? - Will a single binary be suitable for both M1 and x64 architectures?
If the answer to these is yes, then the builds on the NightlyDevel Release page should be M1 ready.
So I don't use projucer but
if you can set your architecture to "x86_64;arm64" then Xcode and clang will do the right thing
in cmake you do this by setting CMAKE_OSX_ARCHITECTURES="x86_64;arm64"
You can tell if it worked by running lipo -s Odin2.component/Contents/MacOS/Odin2 and that will tell you the arch
I spent exactly zero time on that patch. But I did spend a bit of time putting exactly that code into surge when I got my M1. For Odin it was just copy and paste :)
@oiwn @magnusja Could you give the version on the NightlyDevel Release Page a test spin? It would be nice to know that functionality is working before releaseing the build into the wild. I don't have an M1 myself to test it.
@TheWaveWarden you can also check by doing lipo -archs Odin2.component/Contents/MacOS/Odin2 and it will print the architectures which the binary supports.
@oiwn @magnusja Could you give the version on the NightlyDevel Release Page a test spin? It would be nice to know that functionality is working before releaseing the build into the wild. I don't have an M1 myself to test it.
on the first glance everything working. But there is only 2 option to scale the UI 100% and 150%. 100% is too small while 150% is too big, would be nice to add something in the middle.