bugfix replace deprecated fmod system fft call with future compatible calls

[ofTheo]

This allows us to update the fmodex.dylib to support Big Sur without getting linker errors.
Also compatible with current fmodex.dylib.

[ofTheo]

don't merge this yet - latest fmod with Apple Silicon support doesn't have these calls either 🤦‍♂️

[ofTheo]

Okay this is now working with the newer FMOD api ( which is needed for Apple Silicon and Big Sur ).
The new approach requires us to do our own binning as the new api doesn't allow us to specify the number of bands so there might be some small changes in the FFT results. Testing against the old approach it actually seems a little better in terms of distribution and we have more options in terms of nBands requested.

NOTE: We'll need to update headers and libs for all platforms even though the api changes are minimal.

Some references which were helpful:
https://www.parallelcube.com/2018/03/10/frequency-spectrum-using-fmod-and-ue4/

FMOD reference for transitioning from older api to newer:
https://www.fmod.com/resources/documentation-api?version=2.0&page=white-papers-transitioning-from-fmodex.html#fmod-studio-core-api-versus-fmod-ex-core-api

[ofTheo]

I have all the new fmod platforms libs up here:
http://ci.openframeworks.cc/libs/fmod/

I am thinking to add a fmod.sh formula for apothecary and then update the OF codebase to use fmod instead of fmodex as all the libs are no longer called fmodex ( since the last 9-10 years ). I think this will be a bit clearer than using the old fmodex naming when referring to the newer non fmodex api ( 99% is the same just the few changes in this PR ).

That way fmodex.sh still works as it currently does in apothecary and all the old links / urls will remain for the older fmodex libs.

Before I go down this path I would love some thoughts on this.

The other option would be to rename the fmod libs / folders to be the same as the old one but would sort of mask the library naming and the fact that its a more recent version.

[arturoc]

yes that sounds like the way to go.

[oxillo]

Shouldn't we move fmod to an external addon ? It's licencing is very restrictive (you need a license as soon as you use it for money-making activity including internal use in a company). see also #5490.
If we don't go the addon way, I would suggest that

• Of is compiled without FMOD support
• FMOD is only available throudh a dedicated compiler option
• Licence.md is updated to highlight these license issues/risks.

[ofTheo]

@oxillo Hey - I think that makes absolute sense for the future roadmap. Either way as this is a patch release to get OF working on macOS again I think we should keep this in for now.

[danoli3]

Yeah I always have straight away removed fmod for this reason from any commercial macOS projects. Would agree with this path to prevent issues

…

On Fri, 25 Dec 2020 at 4:42 am, Theodore Watson ***@***.***> wrote: @oxillo <https://github.com/oxillo> Hey - I think that makes absolute sense for the future roadmap. Either way as this is a patch release to get OF working on macOS again I think we should keep this in for now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6639 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGK2HH4KB5RETJPR4MHCQ3SWN4PDANCNFSM4UGBTAKQ> .

[danoli3]

100% had to patch it out for some AbletonLink tests I was doing on macOS yesterday. Lets rip it out asap

…

On Fri, 26 Feb 2021 at 12:38, Roy Macdonald ***@***.***> wrote: Hi! I second @oxillo <https://github.com/oxillo> We should get fmod out of the way and simply leave as an optional thing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6639 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGK2HHG265GCC4UTQVNDEDTA33QRANCNFSM4UGBTAKQ> .