I may have misunderstood your question, Gargoyle. Given your background in composition I figured you'd want to know to what extent you have to be able to code your music (or sound design) into the game. From that perspective, 95% coding and 5% musical stuff seems very off. If you really want to get in audio programming subjects such as listed in EA's ad ("direct sound, sound file formats, data streaming, data compression, and MP3 handling"), that's something different altogether, although FMOD can handle a great deal of that.
Now, I'm not nearly as experienced as the others who have posted above. A year ago I hadn't landed any game music gigs yet. So perhaps our situations are slightly comparable. In my case, learning middleware really helped to get that first job. As an indie team with neither audio designers or audio programmers, getting someone in who knew how to work with FMOD made for a great addition to the team. Not only did it make for efficient implementation, it also drastically improved the quality level of the game's audio.
With the arrival of musician-friendly middleware, it's become much more feasible for someone with a background in purely music and/or sound design to implement audio without requiring thorough understanding of programming languages. Myself, I know little to none and can't write a basic set of code--but I do know my way around FMOD and the visual programming approach in Unreal Engine. It's allowed me to implement 90% of the audio of the Unreal Engine project I'm currently involved with, including complicated music and sound events with transition zones and various parameter functionalities connected to varieties in in-game situations.
The tools you work with change the product you create. Using middleware can really alter the way you write music once you get the hang of transitions and parameters. For sound design, using middleware seems almost mandatory if you want to avoid monotony and aim to achieve a realistic sound in a resource-efficient way--especially if you're not savvy in programming.
The team I work with consists of 10 people at most. They don't have the resources (nor the need) to get another audio guy on the team in order to split the audio programmer and audio designer jobs. So the roles are merged: the designer also programs. So far, that's mostly concerned implementation and bank management. In larger teams it makes more sense to divide the tasks among specialists, so the designer creates the sound and the programmer implements it and makes sure streaming, compression and mixing routes are managed properly. I remember raising a brow when I saw a audio programmer in Ori and the Blind Forest's credits. It makes sense to have a dedicated audio programmer in large teams and projects, but I just hadn't seen that in credits before.
Long story short: I haven't the extensive background yet to provide a solid, undoubtful analysis of what's expected of you as an audio programmer and/or audio designer. From what experience I have, I'd say that while high quality composition will always be valuable, skills in middleware make for a big plus and skills in implementation form another much desired ability. Especially in small indie teams where resources and manpower are limited, being able to do audio from production to implementation can be highly valuable.
This summer, we've had a thread about FMOD and Wwise (
here). Perhaps you'll find something useful in there. I'm not sure to what extent Wwise is used on an indie level; it's definitely used in AAA projects. Assassin's Creed Black Flag composer Olivier Deriviere spoke about it at a conference last year (read more about what he talked about
here). FMOD has flexible license fees and is used in both low-budget indie games and AAA games such as World of Warcraft and Forza.
Developer
