


       Computer music as a field has been likened to a            
       building with a sign on it saying "Best Eats in Town". 
       Many people go into this building expecting to find an     
       elegant restaurant with a parchment menu, formidable wine  
       list, and pleasant, efficient, even charming service. What 
       they find instead, to their surprise, is a shiny, enormous, 
       extremely modern kitchen, with abundant supplies of every  
       kind of foodstuff in voluminous, refrigerated storage.     
       Indeed, the "Best Eats in Town" are available here, but only 
       for those willing to learn to cook! (Moore et al. 1983)




Foreword


Moore's cooking metaphor is extremely accurate for the work we are
proposing: the computer instruments in our catalogue are like the
abundant, frozen supplies of a digital sound kitchen. It is up to
the reader to determine the potential courses of the menu by
assuming an active role in there. To those who do, the Amsterdam
Catalogue of Csound Computer Instruments (ACCCI) offers "The Best
Eats in Town".

In digital synthesis, sounds are represented by a sequence of
discrete numbers. Hence, a digital audio synthesis technique is the
specification of a computing recipe or mathematical formula, which
computes each number. Special hardware converters are used to
transform the digital sequence of numbers into the corresponding
analog voltages of a continuous signal. The electrical current will
then drive loudspeakers and render the digital stream audible. 

Software sound synthesis (SWSS) programming languages offer a
universal audio processing environment for the implementation,
development and exploration of digital sound synthesis
techniques. The first SWSS languages date back to the suite of
programs named Music 1 through Music 5 (Roads 1983). They were
written by Max Mathews at AT&T Bell Laboratories in the late 1950s
and 1960s. Numerous descendants followed, adapting the basic
paradigm to new software technologies and new generations of
computers. At present, three SWSS packages are widely used in the
research community: cmusic, Csound and cmix (Pope 1993). 

While there are numerous differences when it comes to the details,
SWSS languages also share one important similarity. Basically, they
all follow a modular approach to sound synthesis. Each module of
the language is either generating or modifying a stream of numbers
(an audio signal) and any number and type of modules may be patched
together in a network. In SWSS terminology the modular networks are
referred to as computer instruments.

Owing to this similarity, SWSS instruments are often represented
graphically by flow charts which show symbols of the modules and
the associated data flow between them.

In SWSS languages a musical note is defined as a collection of
acoustical parameters. Many computer instruments share a common
basic set of acoustical parameters: starting time, duration,
amplitude and frequency of the event. But past this minimum
collection of parameters, different computer instruments offer
various amounts and types of free acoustical parameters. In the
ACCCI, we have singled out all parameters that exceed the minimum
set as additional parameters. This gives direct insight into the
complexity of the computer instrument's interface. 

Number, type and interaction of acoustical parameters are crucial
for real time computer instruments, played by musicians. Each
parameter should have an expressive range which makes sense to
human perception. If this is not so, parameters are better
incorporated in the instrument definition, where they do not burden
the human interface. Of course, these limitations do not hold in
software controlled composition, where parameters can be played
by functions with inhuman patience and precision.


Project Outline

For the past three decades, along with growing computational
potency, there has been a proliferation of research devoted to one
or other digital sound synthesis technique. The wide range and
diversity of these techniques are hard to put in perspective
without practical exploration. Therefore, a common library of SWSS
computer instruments can be of use in various fields of research
and modern composition. One can ask why this obvious demand has not
been met up to date, and perhaps the answer is, at least in part,
due to the complexity and vastness of the task.

There are three major sources of data for such a catalogue. In the
first place, two catalogues of Music 5 type of computer instruments
(Lorrain 1980; Risset 1969) have been published. In particular,
Risset's Introductory Catalogue of Computer Synthesized Sounds
has been a source of inspiration for our work. It contains about 25
SWSS instruments illustrating sound synthesis or perception issues
and has been of great use to many. Yet today, the Music 5 sound
compiler is obsolete, and Risset's instruments cannot be run
without translation into one of the currently available SWSS
languages. Secondly, the literature on digital sound synthesis
techniques offers relevant data and flow charts for
computer instruments -- but lacks the actual implementations in a
SWSS language. Computer instruments would form a very welcome
empirical complement to the theoretical expositions
presented in current computer music literature. In the third place,
we find a reversed situation by looking at the large number of
undocumented, heterogeneous computer instruments distributed with
MIT's Csound software (Vercoe 1993). The lack of proper
documentation and multiple programming styles -- ranging from
cryptic to intelligible -- lessen, to put it mildly, the access to
potential insights and knowledge that might otherwise be obtained
from those instruments.

Given this state of affairs, we have made it our choice to
contribute to this situation's improvement by compiling the first
catalogue of Csound computer instruments. The catalogue
is to systematically organize computer instruments by
topographically uniting literature, programs and documentation
concerning each synthesis technique. Our primary goal is to
represent several synthesis techniques in a uniform and clear
programming style and thus provide both perspective and more
transparency to the wide field of sound synthesis.
The Csound language has been chosen above the cmix or cmusic
languages for practical reasons. It is distributed by Internet host
cecelia.media.mit.edu and runs on many different computing
platforms.

So as to not invent the wheel twice, we have actualized all of the
material Risset presents in his early catalogue by translating it
into Csound, and reclassifying it according to our taxonomy. In our
view, it is disadvantageous to alienate a catalogue of sound
synthesis techniques from its historic dimensions: the experiences
of the past are and will remain extremely valuable for the
understanding of the nature and art of sounds.

Thereafter we proceeded by including instruments representing more
recent synthesis techniques, based on articles. We analyzed and
provided with clear documentation some of the MIT instruments
mentioned above. A few classes of the ACCCI are exploring specific
elements of the Csound language. In a later stage of our project,
we have addressed the development of new instruments. Basically, we
have intended our catalogue as a work in progress and as a
contribution towards facilitating the work and investigations of
those concerned with sound synthesis techniques.

We have presented the results of our work in a twofold manner:

       i. In a closed form -- an encyclopedic version in one      
          document -- intended for the purposes of study and      
          consultation;

       ii.In an open form -- an interactive version consisting of 
          a large collection of files and their associated        
          directory structure -- meant to grow in the years to
          come... and to eventually outgrow the limitations of this 
          document.


Lay-out of the Catalogue

Overview 

The ACCCI is conceived as an open system, leaving room for new
instruments. At the same time, it provides a rigorous framework for
experimental sound synthesis, where experiences made by Csound
users can be suitably placed in the catalogue. Here are our
guidelines: 

   - use the ACCCI number code to classify all files that
     are related to one instrument

   - a main group of the catalogue starts with two pages    
     of general information: contents, overview and sug-    
     gested reading  

   - use the same variable names for the same parameters
     throughout the catalogue

   - use a distinct header with name, synthesis group,
     programmer, date and other relevant information (.ORC
     and .SCO files)

   - start the actual instrument by assigning the p-field
     variables to the mnemonic variables, i.e. idur = p3.
     (.ORC files)

   - provide comments clarifying the instrument design 
     (.ORC files)

   - add the mnemonic variables in a comment at the begin
     ning of the actual score (.SCO files)

   - keep a textfile (.TXT) with an informal description
     of the instrument design, experimental directions,
     subjective impressions, reference articles, etc.

   - instrument flow charts (.EPS files)

Sampling Rate and Control Rate

The sampling rate will be set to the 44.1 KHz CD standard. This is
to ensure ready-to-use programs on different platforms. We
refrained from the use of K-rate variables in many programs. As the
computational resources continue to grow, the gains due to the
K-rate/A-rate differentiation decrease. On the present generation
of personal workstations it is no longer worth the additional
effort, especially when one bears in mind that the differentiation
can lead to losses in audio quality: ".. many instruments sound
significantly different when run at K-rate=A-rate than they do in
'debugging mode', a feature which has caused this author many hours
of consternation." (Pope 1993: p.38). Yet, some unit generators do
not accept A-rate inputs, so K-rate remains necessary at times.

Naming Conventions: Files
 
A number of data files are associated with each SWSS instrument.
These files are solely differentiated by their filename extension,
but otherwise carry the same name.

.ORC   Csound orchestra file
.SCO   Csound score file
.EPS   Encapsulated Postscript file: flowcharts, functions
.TXT   documentation
.SF    soundfile

The name of the instrument conceals a coded classification, that
divides the corpus of SWSS instruments into main synthesis groups
and their individual subgroups. The filename is composed of three
different numbers in total, each of which is delimited by the
underscore. The first number refers the instrument to its main
group, while the second number associates it to a subgroup of its
main group. The division in two hierarchical levels enables one to
keep track of particular instruments without creating excessive
overhead organization, and is considered a practical and necessary
tool when working with a large number of files. Within the ACCCI
directory, orchestra and score files are kept in folders, named
after the number code of their main synthesis group. It was not
necessary, at this stage of the database, to further subdivide the
directory structure into subgroups. The third number -- ID --
identifies a particular instrument within the main and subgroup.

For example, the file 01_12_1.SF is the soundfile of an instrument
and its name 01_12_1 contains three codes:
 
01     the main group code
12     a subgroup code of main group 01
 1     ID code within subgroup 01_12

Appended letters (e.g.: 01_12_1B) serve to indicate different
versions of the same instrument. 

Our naming convention is made independent of a particular operating
system by restricting the name length to a maximum of eight
characters and by choosing the underscore as delimiter between
number codes. We would prefer the dot as delimiter -- as it is
commonly encountered in library classifications -- but the dot may
not be used in DOS.Naming Conventions: Variables

- the first letter
The first letter is always i,k or a (or g for global variables) and
specifies the rate of the variable.
 
- the body of the variable name
Mnemonic of their parameter, the following variable names have been
adopted throughout the ACCCI. Whenever possible, the variable names
used in the MIT Csound manual are respected.

amp    amplitude              form   formant frequency
atss   attenuation ratio      fq     frequency
att    attack                 lh     lowest harmonic
beg    begin                  meth   method of decay
buf    buffer size            mid    middle
bw     bandwidth              mod    modulated signal
cfq    center frequency       nh     number of harmonics
dec    decay                  oct    octaviation
del    delay                  off    offset value
dur    duration               pcf    pitch contr. function
dyn    dynamic index          pch    pitch
env    envelope               sc     scaling factor
f      function table         src    source signal
ff     formant frequency      stsec  start second
fil    file                   tf     transfer function
fn     function number        timpnt time pointer
fund   fundamental frequency  val    value
ind    index                  vib    vibrato

- the last character
To further characterize variable names, we sometimes attach an
extra letter to the end of the variable name, mnemonic of the
function of that particular unit generator. For example, ifc may be
the function table variable for an oscillator that generates a
carrier signal. The most frequently attached mnemonics are:

c      carrier                m      modulator
e      envelope               r      random number
i      index                  w      wave 

We also attach numbers to the end of the variable, but they usually
convey less meaning. In orchestras with many variables of the same
type, numbers are necessary. The decay time of the 4th envelope
function of an additive instrument is idec4. 

Naming Conventions: Table Numbers of the F Statement

Reserving certain table numbers for specific categories of table
generators has several practical advantages. When assembling big
orchestras from smaller ones, functions will be more readily
adapted to the new environment. This leads to a more efficient,
faster experimentation or composition. The convention overloads the
first parameter of the f statement by reserving table numbers 1-30
for carrier waveforms, 31-70 for envelopes and 70-99 for others.
Hence, the number of a GEN function table will additionally
discriminate an oscillator as carrier or envelope generator, and
even add information about the type of wave being used.

Function tables numbers are restricted to a soft limit of 200
(Vercoe 1993b: p.50). This feature will hopefully disappear in
future Csound updates to facilitate the creation of a larger
function table library with associated graphs. In practical terms,
any instrument of the catalogue will obey the following conventions
of table numbers:

GEN     Table   Function 
number  number  type

10       1-10   harmonic complex 
09      11-20   weighted (in)harmonic, phase-adjustable
11      21-30   buzz
07      31-50   linear 
05      51-70   exponential
01,02   71-80   read into table from file/parameter fields
        81-99   others

Position of the Score File Parameters

Whenever present the basic five acoustical parameters are
maintained in the same sequential order on the event lines of the
score files. 

p1           p2         p3          p4           p5       

instrument   start      duration    amplitude    frequency        
number       time                                or pitch

Other parameters are left free to vary in their position, according
to the changing contexts of particular computer instruments. 


Interactive Version 1.1

The Internet version of the catalogue is available via anonymous ftp from 
mars.let.uva.nl. Directory /pub/accci.  We provide archives for DOS, NeXT, 
Sun and Macintosh platforms. 


Encyclopedic Version 1.1

The catalogue is also available in bookform, 200 pages with illustrations 
and programs. The format is landscape, printed double-sided.  The main 
advantage of this general document lay-out is to permit the display 
of all the information and programs belonging to one SWSS instrument on
two adjacent pages. 


Acknowledgments

I wish to thank my mentor Leigh Landy for supporting and
encouraging this catalogue from the beginning. His enthusiasm for
experiments in music has greatly stimulated my own research. 

Thanks are due to many other people at the University of Amsterdam.
In particular I thank Louis Pols and David Weenink at the Institute
of Phonetic Sciences for giving me the opportunity to run the
synthesis programs on a Silicon Graphics workstation. For the
correction of my Germanic English I am indebted to Marije van
Wieringen. I received valuable advice from Remko Scha and Henkjan
Honing at the Department of Computational Linguistics. Edwin
Brinkhuis has helped in providing logistical support, a laser
printer and a glass of beer when the pubs were closed. 

From the State University of New York at Buffalo, I thank Cort Lippe 
for helping in organizing practical aspects of my work on the LAN. Also 
thanks to David Fuller for keeping my TA schedule flexible enough to 
finish the work I begun in Amsterdam. 

Last, but not least, I wish to thank my friend Andrs Zlotsky for
his love, patience and cooking. Our red cat Alexej Dimitri Catovich
deserves the co-authorship of the catalogue, because he pressed the
right keys when I forgot what I wanted to say.   



John P. Gather
jpgather@acsu.buffalo.edu