Next: 1.2. Where is the parallelism in sample
generation?
Up: 1. The Problem
1.1. Problem Specification
There are two inputs to the synthesis system:
- Score File
The score file contains a list of notes that comprise the piece to be
synthesized. For each note, the score specifies an instrument, a start time, a
duration, and any number of optional parameters, such as frequency and loudness.
- Orchestra
The composer also specifies an orchestra: the set of instruments to be used in
the piece. Most systems require the composer to write C or FORTRAN functions that
instantiate the appropriate unit generators and map the score file parameters
into these
new instances. Many unit generators have inputs as well as outputs; hence, each
note in the piece induces a separate tree of unit generators.
The goal of software synthesis is to generate a stream of digital samples from
the given information as rapidly as possible. An interesting variant of this
problem arises when the note list is derived from a music keyboard rather than a
score file and the
samples are generated in real-time as the keyboard is being played.
Viewed mathematically, the sample stream fo
r a given note is simply regular sampling a time-varying, single-valued function
-- the synthesis algorithm. Unfortunately, there are few helpful formal
properties these functions share. For example, if all synthesis algorithms had a
closed form then sam
ples for a given note could be computed in any order. While the frequency
modulation (FM) technique has a closed form, techniques which rely on digital
filters (including the Karplus-Strong plucked string algorithm) compute a new
sample based on some state
variables, precluding a closed form. In these situations, the implementor is
forced to compute the samples in strict order.
[Bill's Home Page]
Comments to walker@shout.net