Building in macOS 11.0 Big Sur

yes! that’s what it defaults to currently.
If you just do the fmodex fix above it should run fine with Rosetta

I’m getting this too but still in Xcode

Hey - I can confirm this. Looks like _FMOD_System_GetSpectrum was removed from the fmod api quite a while ago. We’ll need to find a replacement function using the newer approach.


Unfortunately the transitioning documentation has been removed from the fmod site.

thank you, runs fine on M1 with the fix :slight_smile:

And if I may add to the hype. And in case anyone cares. It feels blazing fast on an macbook air m1 with 8gb. Comming from an 2018 13“ pro with 16gb ram. It took way longer for the inital compile and ran extreemly hot in debug. This one seems 10 times faster. I am more on the nooby side in terms of the internals but if somehow openframeworks becomes native m1 it should be blazing fast.

1 Like

Should I get this on the github issue tracker or are you already tracking it?

Thanks @TravelByRocket !
I’ve added it to the 0.11.1 list here:


Any suggestions on a workaround in the meantime? I really don’t need anything related to sound to work for the project I want to get going on.

Any suggestions on a workaround in the meantime? I really don’t need anything related to sound to work for the project I want to get going on.

If you comment out these lines in ofSoundPlayer.cpp

and this line in ofSoundPlayer.h

It shouldn’t give you anymore linking errors.
Hope that helps!


1 Like


1 Like

Hi Theo, many many thanks for the help!

It worked for me, only I also had to comment out:

This line from ofFmodSoundPlayer.h:

And all these lines from ofFmodSoundPlayer.cpp, from here:

…up to here:

to get it linking.



Thanks for that. It corrected the problem for the specific project, but is there a way to set the updated install_name_tool string for every existing and new project? I did a full disk file contents search and didn’t seem to find it in any location that would imply global scope for Xcode. TIA.

I found the modern FMOD API calls to replace that missing function.
You can see the changes in this PR if you need to use FFT with Big Sur in the meantime:


If you wanted to replace it for new projects / examples:
You would change this line here in scripts/templates/osx/emptyExample.xcodeproj/project.pbxproj

install_name_tool -change @rpath/libfmod.dylib @executable_path/../Frameworks/libfmodex.dylib "$TARGET_BUILD_DIR/$$PRODUCT_NAME";

Then you can use the project generator to make new projects with this fix. Or with the advanced options enabled in the cog of the you can then do ‘update multiple’ and select the examples folder to update all the examples with this change.

1 Like

Thank you so much for the solution of this.

I’m glad if anyone help me to direct how to replace fmodex dylib with the latest one.
I opened zip file and terminal is opened. and I’m not sure what to do next.

sorry for the beginner’s question, Any help will be greatly appreciated.

I solved the problem by myself, thank you for the solution.

Here is what should be a BigSur / Apple M1 friendly version of 0.11.0.
Still working through a few kinks on our CI but I tested this version on both a Apple Silicon M1 mac with Xcode 12 and a Intel Mac running 10.14 with Xcode 11.

Please share any issues you run into in this thread.



just had a quick test. seems to run fine here on m1 air base model. thank you very much :slight_smile:

1 Like

great - glad it works for you!

1 Like

Tried the new build on 2020 Intel MacBook Pro w/macOS 11.0.1 - corrected the mode linker error. Thanks!