Designing Sound

Efficiency of Parameter Space
Later, when we study additive synthesis of bell sounds, and then bird sounds
using modulation techniques, we will see two opposite examples. The first
requires a large number of parameters to produce only a few rather similar
sounds. The latter has only a few parameters, but it produces a vast num-
ber of very different sounds. A model and implementation are good when
they offer an efficient parameter space; we say the design
captures
the sound
well.

---

16.10 Practice and Psychology
261
Factoring/Collapsing
An aviation analogy for a moment, you may have heard: “There are old pilots
and bold pilots, but no old, bold pilots.” The parameter space of age and
courage has a mutually exclusive area; the product of age and courage is a con-
stant. Reducing a large parameter space to a smaller set of more useful controls
is rather like this. It involves removing the parameter combinations that don’t
make any sense. Let’s say we have a model for some imaginary process like
a rigid body impact. For this, we have three parameters, attack time, decay
time, and the frequency of a filter. But we notice that all the sounds we are
interested in combine these parameters as a subset (subspace) of all the possi-
ble ones. When the attack time is sharp, the decay time is long and the filter
frequency is higher. It seems there are never sharp attacks with low-filter fre-
quencies and short decays. If we can find three functions that map a single
parameter on to the other three, let’s call it
impact energy
; then we can col-
lapse the space and reduce the complexity of the interface. We end up with one
parameter that captures all the behaviour we want.
SECTION 16.10
Practice and Psychology
The above process depicts an ideal. It is the perfect chain of work that assumes
that everything follows in a neat sequence and we get everything right the
first time so it’s only necessary to go through the steps once. In reality, design
requires several passes, and not all the steps will happen in a nice order. Anal-
ysis always comes before synthesis. Each time we approach a new sound we
will ask questions to deconstruct the sound into its essential physical produc-
tion mechanisms. Armed with these, we attempt to fit them to known synthesis
tricks or methods that can efficiently emulate physical behaviours while offering
useful controls. Finally, we will build a level of behavioural abstraction on top
of this to give control. In real life each step will be imperfect and require us to
revise the analysis, model, methods, and implementation over and over again.
This can be seen as a cycle, with the designer sitting in the middle trying to
balance all the parts in a circle of work. A more modern software engineering
practice that describes this process is called “agile development,” where fast
iteration over smaller chunks of the design and frequent updates to the design
document are made. The motto “fail early, fail often” discourages too much
design without testing.