Information Technology Reference
In-Depth Information
to case, and for a high level treatment we can
take exchangeable implementations as a given.
It's worth noting that there is an axiomatic set
of a few operators including such “atoms” as the
unit delay (Z
-1
) and arithmetic operators (plus,
minus, multiply, divide) from which all of DSP
can be obtained. In native implementations, many
constructions can be built upon this foundation,
such as the
sin
() and
cos
() functions approximated
by polynomials (truncated Taylor/Maclaurin),
familiar band limited waveforms built on known
identities, continued fractions or closed forms, and
standard filter blocks built on established topolo-
gies (biquad and so forth). Recently attention has
been drawn back to computational physical meth-
ods (specifically finite difference methods for one
and two dimensional wave equations) which have
come from Bilbao (2009) and, which combined
with the earlier waveguide work of Smith (1992)
and trends toward matrix processors, offer hope
for less expensive versions of direct computation
for plates, surfaces, tubes and volumetric extents.
In practice, as you develop procedural audio
systems, current technologies and runtime con-
straints will determine implementation for you.
Designing Sound
gives some coverage, both as
proof of methodology and an example set for
implementation using the Pure Data language.
Many of these have been translated to SuperCol-
lider by Dan Stowell at Queen Mary University,
London. We must also remain mindful of low level
programatic and architectural issues, such as why
to avoid memory lookups, data bus throughput,
stack frame overheads, the danger of denormals,
and even simple things like watching for divide
by zero, though these are addressed at the C code,
compiler or assembly level and depend on the
underlying hardware too.
The choice of a language and its features is
another subject. Visual dataflow is certainly an
advantage for productivity, readability and reuse.
It has a natural congruence with the thought pro-
cess during design. It has a wonderful granularity
combining simplistic concretes alongside abstract
concepts. Yet in the form I use it, as Pure Data,
it is far from perfect. Nonetheless it probably
represents the best hope currently available for
designing procedural audio due to the ease with
which large programs can be constructed. A nice
overview of language design for the particular case
of musical synthesis is by Günter Geiger (2005).
The general case of synthesis (everyday sound
effects created using procedural sonic objects)
is not addressed by Geiger's study. While Pure
Data seems ideal for design, deployment may be
much better served by those languages having a
“built from the ground up” client-server model
like Chuck or SuperCollider.
Beyond a comparison of algorithmic com-
plexity in relative technologies, such as Avanzini
(2001), a research opportunity exists here for cost
metrics of implementations on modern vector
processors, such as CUDA on Nvidia GPU (see
Angus and Caunce 2010). Briefly, the qualities
to be considered are trans-structural concurrency
(parallelisation) for which functional LISP type
evaluations seem suited (though suffering from
overheads associated with functional languages),
plus those that handle instance concurrency
(source polyphony), like SuperCollider or Chuck.
Other issues are core language size (for example,
MPEG4SAOL Csound or Lua Vessel), scalabil-
ity, whether objects should be pre-compiled or
whether an interpreter or server/client model is
best, and licensing for commercial development
(for example, Pure Data or Max/MSP).
cOst AND VALUE
Of those design qualities on orthogonal axes,
cheap, good or fast, the ground in procedural
audio is similarly divided between a mixture
of expedient design, aesthetic realism, efficient
code, and object flexibility. Flexibility in terms of
software engineering benefits is worth investing
in because reuse, polymorphism, and free asset
generation are amazing advantages available
Search WWH ::
Custom Search