Hello!
I am working on a new mac with an M1 processor, and am finding that I cannot open any of the FluCoMa objects in Pure Data. As soon as any of these objects are loaded, Pd abruptly crashes, without a report being sent to the User Logs.
I have mac’s “security blockade” turned off and have encountered the same behavior whether starting Pd from terminal or elsewhere. I have added the the FluCoMa folder both within ~/Library (using paths) and locally in a patch using [declare -lib], and have also tried loading it using these methods from outside the ~/Library folder (in case of some odd access issue).
I wonder if others have had these issues.
I found this previous post concerning an identical sounding problem occuring on an older Mac (2010)
However, I think this might be a bigger issue than just old macs:
"Apple’s Rosetta does not support AVX as of macOS 11.1 (Big Sur):
Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions."
I wonder what a way around this might be…advice?
Thanks, this work looks fantastic and I can’t wait to try it out.
Jorge
Great to see you here. This will almost certainly be a Rosetta 2 thing, because M1s use this to translate x_64 code on the fly, and it doesn’t support the instructions that our binaries are compiled with.
The simplest thing is to recompile on your machine with these instructions turned off. Do you have the wherewithal to do that? If not, then I’ll try and do a non-AVX build as soon as I can (but it won’t be immediate).
Hey! Its good to see you too, I wasn’t sure if you would recognize me. I hope we can see one another in person at some point!
Ok, well I will try to recompile with those instructions turned off.
I may need pointers down the road but I have used Cmake a bit and the instructions on github seem clear. I am just not sure where to turn off those instructions, but perhaps it will be obvs once I get into the compile process.
Will try it very soon and return with questions or (hopefully) new objects.
Yes! Have you moved up further North for your new gig? I’m not yet allowed to travel to England, but that should lift soon, I hope.
Given that this is becoming A Thing at the moment, we could possibly highlight it better, but per this section of the readme, you want to try adding something like -DFLUID_ARCH=-march=native to your cmake command.
Well, I changed it from the Actually Wrong mnative to march=native. Although I’ve seen things saying one should prefer mcpu to march on Arm, I haven’t yet reached the point of Understanding Why. AFAIK, it should still have the desired effect here, no?
Assuming architecture detection works for your platform, passing “native” is usually the best choice if you’re not cross-compiling and all you care about is performance.[3] With the GNU compiler, all three flags can accept “native” as a parameter so -march=native, -mtune=native, and -mcpu=native are all valid.
BUT
LLVM compilers only support “native” for the -mcpu and -mtune flags. You cannot use -march=native with LLVM-based compilers. If you’re not cross-compiling, always use -mcpu=native to maximize optimization and compatibility across compilers.
I shall fetch a rug update the READMEs to mcpu instead.
nope; this is a native build of SC3 on M1 and I (briefly) tested it with the Neural Network Controls Synth from 2D space (all on server).scd file… at least that part seems to work pretty well…
One annoying thing about M1 builds at the moment, IIRC (don’t have an M1) is that CMake will default to building the architecture it itself was built with, so if CMake is running under rosetta, it will default to x64.
