Apart from regular tools (DAW, audio
editor etc...), it is a common thing
for a sound designer-composer to
learn/use programming tools (like
Unity or FMOD) to be able to
implement-test audio myself during the
development?
It's not common, because game (and sound) programming requires a certain level of experience in programming to make the person effective in writing code. You'd need to double yourself as a decent programmer for it to be effective for you to write code as well as create sound. Your primary job is to create music and/or sound and to specify its in-game behaviour at some level (usually using tools like FMOD, Wwise etc.).
The sound person rarely does the actual audio calls or procedures, because doing that requires understanding of how the game code is structured. The sound person may be required to write short scripts (that may have a custom, simplified syntax or that may be in an actual programming language e.g. Python, Lua, C# or a markup language e.g. XML) that specify which sound file plays and how it plays when a certain audio event is called from the game code. The scripts are then linked to the game code in some way. The scripts are short and simple and learning to write them, when they're needed, shouldn't be a problem, but knowing the basics of imperative (or object-oriented) programming in some programming language helps and should make different scripting syntaxes and styles very easy to grasp.
If the game developer uses an audio middleware (e.g. FMOD, Wwise) or a framework (e.g. XNA) that has a separate "designer" program or view for audio, then you usually don't need to write anything, because everything that you need to handle is handled via the graphical "designer" program that basically works just like any other program.
If the game uses/is built on a very sophisticated framework that has graphical tools for navigating and editing the entire game build (effectively this is kind of how Unity works), then the sound person can usually adjust the sound and navigate and test builds quite easily.
I already have an answer that is
pretty much straight forward and the
answer is YES. balancing volumes
between GUI sounds, background sounds,
music and other audio events are
crucial elements that need to be
handled by the audio guy to fine tune
his idea before submitting, having a
trained ear and mostly being aware of
critical listening. Also seems
reasonable to me that having access to
the code (audio part only) it'll make
it easy to swap files, test different
solutions in context..
Remember that every person has ears and most people listen to music and other audio. Anyone is as informed (if not just as experienced) as you to make a decision or to form an opinion regarding sound.
delegating all these tasks to the lead
programmer doesn't sound right to me.
I'd say it depends on who does most effectively what needs to be done. If everything is handled via code, then it's easier to just do it, than try to teach someone who doesn't know how to program to program the audio. If you did know what to do, then wouldn't you be programming those audio procedures already?
Also it makes dev more complicated and
longer since there's this ball pass
between the lead programmer before the
audio guy can actually hear things in
context.
That's true and it sucks from audio's part, because audio needs to be worked and listened "in real time" to make decisions and having to wait to hear what you've done is a suboptimal practice. The solution is to use a tool/middleware that allows the sound person to work on the sound and test it independently or almost independently.
been working on 4 games so far and it
doesn't seem it is a common practice.
the lead programmer was in charge to
do all these things. I will actually
start learning these implementing
tools
All learning is good, but depending on what you mean by "learning these implementing tools" you may be taking quite a plunge. Learning to program in a programming language (especially in a complicated language like C++) and to read code, when you're exposed to it for the first time, is hard enough for starters and it'll take a while until you can advance to understanding audio middleware libraries for example. I'm just warning that it'll be complicated and it'll take time to grasp, so be prepared to put the time in.