The SndObj Sound Object Library VICTOR E. P. LAZZARINI Department ofMusic, National University ofIreland, Maynooth, Co. Kildare, Ireland E-mail: [email protected] The SndObj Sound Object Library is a C++ Programming libraries constitute a lower-level in object-oriented audio processing framework and toolkit. computer music practice, when compared to sound com- This article initially examines some of the currently pilers. The context where they appear is more general, available sound processing packages,including sound and consequently their use is more complex. This can compilers,programming libraries and toolkits. It reviews be easily demonstrated by the differences in coding of a the processes involved in the use of these systems and their strengths and weaknesses. Some application similar instrument under csound and cmix (or clm), examples are also provided. In this context,the SndObj which will be shown later. It involves not only the library is presented and its components are discussed in knowledge ofthe syntax ofa particular language, but detail. The article shows the library as composed of a set also the grasp ofconcepts not necessarily needed when of classes that encapsulate all processes involved in using a sound compiler. For instance, with cmix, the synthesis,processing and IO operations. Programming user has to understand variable declaration, memory examples are included to show some uses of the system. allocation, header files, object code linking and other These,together with library binaries,source code and C-related concepts in order to build a sound processing complete documentation,are included in the or synthesis ‘instrument’. The advantage is that, in this downloadable package,available on the Internet. Possible future developments and applications are considered. The case, the programmer has more control over the pro- library is demonstrated to provide a useful base for cesses involved in sound manipulation and can design research and development of audio processing software. applications that will suit better his/her needs. Apart from the mentioned use of libraries as part of packages 1. BACKGROUND: SOUND COMPILERS, such as clm and cmix, there are several other sound- LIBRARIES AND TOOLKITS manipulation programming libraries which were developed for various applications. As examples, two of Since the development, by Max Mathews, ofthe these can be mentioned: the SndLib, developed at MUSIC-series ofsound synthesis programs (Mathews CCRMA for cross-platform sound input/output, and the 1960, 1961) in the early 1960s, several programs for Sfsys, developed by the CDP (Atkins et al. 1987), origin- synthesis and processing ofaudio in a general-purpose ally for their Atari-based sound filing system and then computer were developed. They were mostly based, dir- ported to other platforms (PC and UNIX). ectly or indirectly, on the MUSIC IV model. Programs Another related type ofprogramming softwarelibrary such as these are sometimes referred to as Computer is the toolkit, normally associated with the object- Music Languages, Acoustic Compilers or Sound Com- oriented paradigm. Toolkit objects are normally used in pilers. Some ofthem were developed forspecific hard- programs by direct reference and, sometimes, by com- ware and are now obsolete, whereas others, which enjoyed greater success, were developed under high- position. In general, its use is more straightforward than level languages, like MUSIC V (Mathews 1969), written the standard procedural- or modular-programming lan- in Fortran. Among these, cmusic (Moore 1990) and guage libraries. Examples oftoolkits are the NeXT- csound (Vercoe and Piche 1997), written in C, are two based Music and SoundKit (Jaffe and Boynton 1991), important examples ofsound compilers. Csound is one written in ObjectiveC, and the Synthesis Toolkit (Cook ++ ofthe most interesting sound processing systems avail- 1996), developed by Perry Cook in C . The SndObj able today, not only in terms ofwidespread use and port- library (Lazzarini and Accorsi 1998), although not ability, but also because ofits continuous expansion and designed to be used solely as a toolkit, is also an support by a large development community. Other example. MUSIC-derived sound compilers still in use include clm This section will examine in detail some aspects of (Schottstaedt 1992), which runs in a Common Lisp sound compilers and libraries. First, csound is intro- environment, and cmix (Lansky 1990), which consists of duced as an example ofa sound compiler, followedby a command parser and a library ofC sound-manipulating a small programming example. It is then compared with functions. In fact, both clm and cmix can be considered two library-compiler hybrids, cmix and clm. Examples hybrids ofa sound compiler and a programming library, ofsimilar code forthese systems are also shown. This the former using Common Lisp, and the latter using C is followed by an overview of the object-oriented pro- as the implementation language. gramming paradigm. Completing the section, two sound Organised Sound 5(1): 35–49 2000 Cambridge University Press. Printed in the United Kingdom. Downloaded from https://www.cambridge.org/core. Maynooth University, on 21 Aug 2019 at 09:54:54, subject to the Cambridge Core terms of use, available at https://www.cambridge.org/core/terms. https://doi.org/10.1017/S1355771800001060 36 Victor E. P. Lazzarini manipulation toolkits are discussed, the Sound/MusicKit instrument. The output ofa csound instrument is defined and the Synthesis Toolkit. by the code: out asignal 1.1. Csound,cmix and clm which can be thought ofas a ugen without an output Csound was originally developed by Barry Vercoe at the variable. The input argument is a variable ofthe type a, MIT, but it has been updated and expanded by several which is used to hold audio signals (actually a vector). contributors, this author included. Cmix is the product A simple sine-wave csound instrument is shown below: ofthe work ofPaul Lansky and others at Princeton Uni- versity, and clm originated at Stanford, mainly as a instr 1 result ofBill Schottstaedt’s research. These packages are asig oscil p4, p5, 1 very different from each other, except for the fact that out asig they have common predecessors, the MUSIC-family of endin programs, and similar applications. The main difference The arguments to oscil are amplitude, frequency in Hz between these packages is the user-interface. Csound and function table number (which stores a sine-wave uses basically two text files ofcoded informationas its shape). The variables ofthe type P, p4 and p5, and the input, one containing an ‘orchestra’ file, with signal- function tables are defined in the score file. This will processing definitions organised in terms of‘instru- have a number of f statements which will define the ments’ and a ‘score’ file, with performance instructions function tables used in the synthesis process and a for the ‘instruments’. These two files are given as argu- number of i statements. These define calls to instruments ments to the csound command which compiles the to generate/process audio. For example, audio. Cmix uses only one ‘score’ file, the ‘instruments’ are C-coded and pre-compiled as part ofthe library. The f1 0 1024 10 1 score file is passed to the cmix command (or directly i1 0 2 16000 440 to the instrument command ifyou are using only one is a score that will create a sine-wave function table, instrument) which calls the C programs responsible for defined as number 1, and call instrument 1 to generate a the sound processing. In fact, the score file is not strictly 440 Hz signal, with a peak amp of16,000, from0 to 2 required because cmix works by interpreting commands seconds. The command that are passed to it. These commands are written in cmix’s parsing language MINC, which is very similar in csound -odevaudio sine.orc sine.sco structure to C. Clm works in a Common Lisp environ- will play that sound in real time (sine.orc and sine.sco ment, which is interpreter based. Calls to clm ‘instru- being the orchestra and score files with the code shown ments’ are interpreted similarly to any lisp function. above). Prior to its use, a clm instrument must be compiled and Cmix uses a different principle. Instruments are loaded. A ‘score’ file, based on lisp code, can be written defined as commands called by the cmix environment, to perform all the necessary calls to generate audio. This using minc syntax (Garton 1994). A C compiler is neces- file can be loaded like any other file and the lisp inter- sary, since instruments are coded as C functions and preter will compile the sound. linked to the main cmix libraries and the Minc user-data Csound scores and orchestras are written using a very parsing language. They make use ofsome cmix C func- straightforward syntax. The orchestra file is normally tions, such as setnote(), endnote() and ADDOUT(), divided into two types ofstatements: header and instru- which provide basic soundfile and housekeeping func- ment block. The use ofa header is not compulsory. In tions. Unit generators are also provided, in the form of case ofits absence, defaultparameters are used. The C library functions which can be employed in a user- instrument block statements are preceded by the code defined instrument. The instrument designer has to pro- instr instrument number, and the instrument block is vide a more detailed processing algorithm, including the closed by endin. The general form of an instrument necessary initialisation routines and a processing loop. block statement is csound syntax can be defined as fol- The example below shows a simple cmix instrument lows: which generates a simple audio signal: output var ugen input args double sine(float *p, int n args) { /* p[0] start,p[1] dur,p[2] amp,p[3] freq,p[4] function table */ where output var is any type ofoutput variable (a, k, int n, durs, length, outfile; or i) and input args is any number ofinput arguments float fr, sr, amp, ndx, *wavetable, to the unit generator ugen.