The balance in both the FMOD Studio sound-/music-designer app and the accompanying API is well-judged in terms of simplicity versus complexity. Really simple sound and music design takes no time at all, and a simple runtime sound engine based on the API is similarly simple to code up. Complex sound events, 3D positioning (with customizable roll-off behaviors), and sophisticated interactive music tracks can be designed and auditioned in the app. Admittedly this requires a little more technical knowledge but there's no need for knowledge of C++ programming to achieve this. The app can also connect to a live running game to tweak behaviors in response to the actual live game data, which is invaluable. More complex sound engines using the API are highly customizable too. The API is simple to use and the support forum is very active, and frequented by the actual Firelight Technology engineers (rather than representative to merely triage issues). They are very responsive, in my experience, and they are clearly keen to make FMOD the best it can be. Finally, having used the FMOD Studio app since its very early release, I was impressed with the engineering process (from an external view point) where the initial app was super basic yet developed over time. There is a strong sense that their internal processes for their roadmap prioritization and QA is working well (presumably involving extensive automated tests given the very few regressions I have experienced). Features were added as the FMOD Studio app and API version incremented and these are usually backwards compatible. Review collected by and hosted on G2.com.
I mentioned in my positive comments about the updates to both the FMOD Studio app and the API being "usually backwards compatible". This is less a negative point but something of which to be aware if choosing FMOD Studio as your audio middleware. The FMOD team are great at trying to maintain this compatibility, but sometimes in software engineering there comes a point where a breaking change is, unfortunately, a necessary evil! Due to the way FMOD Studio is developed, improved (and how bugfixes are applied) perhaps the only rational approach if adopting it is to always stay as up-to-date as possible (rather than sticking to a specific point release version for a project). You need to be aware of this in your own project management processes and would recommend including a strategy for updating breaking changes as they happen, rather than accumulating your own technical debt. This is pretty simple to do if you work in an Agile way, especially as the releases of the updates of FMOD are on a predictable schedule. As I said, FMOD appears to respect this problem and avoids breaking changes, they're pretty rare in my experience. As examples there may be times where all the .fspro projects needed to be updated and migrated to new version (clearly this impacts the work of your sound and music teams). On the engineering and QA side there maybe breaking API changes, but these seem to be (and I can't remember an exception) of the type where the build just fails and code needs to be adjusted accordingly (i.e., that's a kind-of good thing!!), rather than subtle behavior changes that could slip through your QA processes. Unless you have a really robust (i.e., full coverage) testing strategy. Review collected by and hosted on G2.com.
