Designing Sound

Structured Approach Summary
Lifecycle
All designs have a lifecycle, starting as a need and ending with a satisfactory
solution that has a finite lifetime. Stages may overlap, as in the so-called
water-
fall model
, but generally each must be completed before the next can be begun.

---

246
Strategic Production
Requirements analysis
The lifecycle starts with a specification of requirements. A script, edited film,
or game plan sets out what will be needed. You must study and clarify this
before moving ahead.
Requirements analysis
Research
Model making
Method selection
Implementation
Integration
Test
Iteration, debugging, improvement
Script / loose specification
Finished product
Product maintenance
Figure 16.1
Stages in developing sound objects.
Research
No requirements specification goes very deep. The next step is to break it down
into chunks and conduct research to gain detailed, specific information about
each part. This may involve collecting documents or analysing data.
Model building
This is equivalent to drawing up a map and waypoints or to sketching a
flowchart of the whole problem. You do not need to know specific implemen-
tation details yet. The model is a definition of an object or set of objects that
reflects all the behaviours set out in the requirements analysis and lists well-
formed outcomes for each.

---

16.3 Requirements Analysis Process
247
Method analysis
This is the stage of creating a sound algorithm. It maps the model onto the
implementation and usually consists of a collection of stock methods. In soft-
ware engineering, these are design patterns. In procedural sound design, they
are DSP blocks in a process chain like “single sideband modulator” or “dynamic
formant filter.” We don’t specify the implementation yet, so a model is portable
between different DSP systems or programming languages. Sometimes we express
a model as a block diagram.
Implementation
Actually building the sound object by plugging together unit generators, pre-
designed filters, and control logic is the implementation. It results in runnable
code taking a set of input data and producing audio as output.
Integration
Next we place our media into the finished product. This process can assume
many forms. It could involve creating instances of sound objects in a DAW
environment, recording them to multitrack, triggering from EDLs, MIDI data,
Lau, or Python scripts in a game mockup, or embedding code into other run-
time objects. It may even be handled by a completely different team, but even
if you are not directly involved you should at least understand the challenges
of this step.