the musician-machine interface in digital sound synthesis

The Musician-Machine Interface in Digital Sound SynthesisAuthor(s): Stanley HaynesSource: Computer Music Journal, Vol. 4, No. 4 (Winter, 1980), pp. 23-44Published by: The MIT PressStable URL: http://www.jstor.org/stable/3679464 .

Accessed: 29/08/2013 01:36

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at .http://www.jstor.org/page/info/about/policies/terms.jsp

.JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range ofcontent in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new formsof scholarship. For more information about JSTOR, please contact [email protected].

.

The MIT Press is collaborating with JSTOR to digitize, preserve and extend access to Computer MusicJournal.

http://www.jstor.org

This content downloaded from 150.108.161.71 on Thu, 29 Aug 2013 01:36:14 AMAll use subject to JSTOR Terms and Conditions

http://www.jstor.org/action/showPublisher?publisherCode=mitpress

http://www.jstor.org/stable/3679464?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp


Stanley Haynes IRCAM 31, rue S. Merri 75004 Paris France

The Musician- Machine Interface in Digital Sound

Synthesis

Introduction

A fundamental consideration in evaluating any music synthesis system is the flexibility offered to the composer in controlling the evolution of a musical structure. In his paper "Design Issues in the Foun- dation of a Computer-Based Tool for Music Composition," William Buxton (1978) outlines some of the problems that arise from the "note equals event" concept on which the existing general-purpose languages have tended to be based. Before considering the tree-structured language that has been developed by Buxton's team at the Computer Systems Research Group at The Univer- sity of Toronto, it would be beneficial to discuss what limitations there are in existing systems and how they might be overcome. Of course, many of the criticisms leveled against general-purpose languages are not so valid when data-preparation systems like Leland Smith's SCORE program are available (Smith 1972). There are, however, no uni- versally available languages for preparing scores for Music 4B, Music 360, or indeed for Music V at in- stallations other than IRCAM. It is therefore often necessary for the composer to write his or her own score-preparation routines in a high-level programming language, and this is beyond the capability of many musicians.

Global Variables in Music V

Of the current general-purpose sound synthesis languages, it is IRCAM's implementation of Music V

Computer Music Journal, Vol. 4, No. 4, Winter 1980, 0148-9267/80/ 040023-22 $04.00/0 ? 1980 Massachusetts Institute of Technology.

that has the most flexible score structure. Music 4B, Music 360, and Music 7 have rather restrictive fixed-field formats for their I-statements (note statements), and although the parameter format is freer in the case of Music 11, the event list is still restricted to data for the instruments and cannot, for instance, contain the arithmetic expressions that are so useful in Music 10 and in the IRCAM version of Music V (Music V [IRC]). The SV1, SV2, and SV3 statements, which set variables in Passes 1, 2, or 3, are unique to Music V and have been available ever since the original 1968 version was released. Although the primary function of the SV1 and SV2 statements, to set global values for groups of notes, can be simulated in the other languages by conditional statements in the Pass 1 or Pass 2 subroutines (Music 4B, Music 360, Music 11) or in the I-ONLY portion of the instrument definition (Mu- sic 10), this is often less convenient. Moreover, the use of SV3 statements to change parameter settings during a note is more difficult to simulate since it involves keeping a count within the sample-processing part of the instrument and making the appropriate conditional branch. The extra code necessary for this (lines a-b in Fig. ib) must be executed every sample and will considerably slow down the synthesis, whereas the modification of the Pass 3 variable V1 in the equivalent Music V instrument (Fig. la) will not appreciably slow down synthesis, since the code to modify V1 is built into the structure of Music V and will only be executed when the SV3 is encountered in the event list. The example also shows how Music 10 simulates Music V's SV2 statements, which are used to set the amplitude for groups of notes.

This example demonstrates another useful feature of IRCAM's version of Music V-the ability to

Haynes 23



Fig. 1. Comparison of run- time variables in Music V and Music 10.

Fig. 1 a. Music V score. Fig. 1 b. Music 10 score.

Fig. la PS1 1;ILN 200;PAC 1;PS2 1; (control variables) INS 0 1; P6=G (30);com set amplitude; STV P5 2; (P5 resets "V" number) IOS P6 V1 B3 F1; (V1 holds frequency parameter in Hertz) OUT B3 B1; END; GEN 0 2 1 512 1 1; SV3 0 1 HZ(440); SV3 4 1 HZ(660); SV2 0 30 1000;com initial amplitude; NOT 0 1 .9 1; NOT 1 1 .9 1; SV2 SV2 2 30 1200;(new ampl) NOT 2 1 .9 1; NOT 3 1 1.9 1; SV3 0 2 HZ(220);com for voice 2; NOT 4.5 1 2 2;com uses V2 (P5=2); FIN;

Fig. 1 b INSTRUMENT VARIABLES; VARIABLE AMPL,/FREQ,/CNT,/SND;

I-ONLY BEGIN IF P1>2 THEN AMPL= 130000 ELSE AMPL=65000; END; (set amplitude)

CNT= CNT+1; (incr sample count (a)) IF CNT>40000 THEN FREQ=660*MAG (from 4 secs FREQ is 660)

ELSE FREQ=440*MAG; (b) SND=ZOSCIL(AMPL,FREQ,F 1); OUTA= OUTA+SND; END; SYNTH(FL); 11 999 PLAY;

VARIABLES 0 .9; VARIABLES 1 .9; VARIABLES 2 .9; VARIABLES 3 1.9; VARIABLES 5 1.9;

FINISH;

specify in note-parameter fields which Pass 3 variables are to be used in the instrument when a particular note is played. This facility, which is invoked by placing an STV in the instrument definition just in front of the module using the Pass 3 variable involved, is similar to the resetting of function numbers (SET, available in the 1968 version) and the more rarely used STB and STP, which

perform similar functions for block and parameter numbers respectively. The ability to select which variable a voice will use allows the user to have several voices simultaneously played by the same instrument even when they use Pass 3 variables. The use of these in the original version of Music V meant that the instruments including them could play only one voice at a time. Notice also that in

24 Computer Music Journal



Fig. 2. Overlapping frequency, amplitude, and modulation index contours.

Frequency 3520

40880 660 Hz

110110

Amplitude 66 48 • 66

54 - - _- I db

24

Index

4 8

S 0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15.16 17 18 19 20 sec

Fig. 1 the note entering at 4.5 sec overlaps with the one beginning at 3 sec and must have a new frequency (220 Hz), which is placed in variable 2 by means of an SV3. Accordingly, a 2 is placed in parameter 5 of the note statement so that V2 is used as the frequency control parameter for the IOS in place of V1, which is used for the first three notes.

Music V's Pass 3 variables are important in that they provide a means of resetting instrument parameters that is independent of the timing of the note statement; this is particularly useful when changes in different parameters do not coincide. It is possible in all of the languages mentioned to link notes smoothly by saving the oscillators' phase parameters, so that a single sound can be made up of a series of segments each represented by its own note statement, but this can be rather cumbersome. A neater way to deal with overlapping control segments is to place the relevant modules in instruments with a lower number than the one pro- ducing the sound. The segment durations can then be isolated in separate note statements and the control parameters individually treated. This method is

available in all of the languages, but Music V offers the additional means of using lists of SV3 statements, resetting Pass 3 variables at the specified times. This is useful in less complicated structures that do not warrant placement of the control modules in separate instruments. The two approaches can be compared in the examples presented in Fig. 3, which shows alternative ways of controlling the evolution of the carrier frequency, amplitude, and modulation index of a frequency modulation (FM) instrument. In both scores line segment generator (LSG) modules are used to perform a linear inter- polation between parameter settings at the beginning and end of a time segment, so that B3, B4, and B5 respectively hold the intermediate sample values controlling the carrier frequency, amplitude, and modulation index. The resulting overlapping glissandi, crescendi-diminuendi, and transitions between pure and rich timbres are represented graphically in Fig. 2.

The use of multiple instruments in any of the general-purpose languages and the additional bonus of the Pass 3 variables in Music V allow the com-

Haynes 25



Fig. 3. Two ways of controlling parameters in Mu- sic

V.

Fig. 3a. Frequency modulation instrument implemented with SV3 list.

PS1 1;ILN 500;PAC 1;SAM 25000; INS 0 1; com set up segments; LSG V1 V2 B3;com carrier frequency; LSG V3 V4 B4;com carrier amplitude; LSG V5 V6 B5;com modulation index; com derive amp & freq for mod. osc; MLT B3 2 B6;com B6 8ve from B3; MLT B5 B6 B5;com peak deviation; IOS B5 B6 B5 Fl;com mod osc.; AD2 B5 B3 B3;com er freq; IOS B4 B3 B3 Fl;com sound; OUT B3 B1; END; GEN 0 2 1 512 1 1;com sine; NOT 0 1 20;com to play all segments; com SV3 list; frqbgn=HZ(440); frqend=HZ(880);segtim=4; (frequency control) SV3 0 1 frqbgn;com initl. V1; SV3 0 2 (frqend-frqbgn)/(segtim* SRATE); frqbgn=frqend; frqend=HZ(660); T=segtim; segtim=3; SV3 L2+T 2 (frqend-frqbgn)/(segtim*SRATE); frqbgn=frqend; frqend=HZ(110); T= segtim; segtim=4; SV3 L2+T 2 (frqend-frqbgn)/(segtim*SRATE); frqbgn=frqend; frqend=HZ(880); T=segtim; segtim=9; SV3 L2+T 2 (frqend-frqbgn)/(segtim*SRATE); ampbgn=DB(54); ampend=DB(48); segtim= 5; (amplitude control) SV3 0 3 (ampbgn;com initl. V3) SV3 0 4 (ampend-ampbgn)/(segtim*SRATE); ampbgn=ampend; ampend=DB(60); T=segtim; segtim=7; SV3 L2+T 4 (ampend-ampbgn)/(segtim*SRATE); ampbgn=ampend; ampend=DB(24); T=segtim; segtim=8; SV3 L2+T 4 (ampend-ampbgn)/(segtim* SRATE); modbgn=4; modend=0; segtim=7; (modulation index control) SV3 0 5 modbgn; com initl. V5; SV3 0 6 (modend-modbgn)/(segtim*SRATE); modbgn=modend; modend=8; T=segtim; segtim=6; SV3 L2+T 6 (modend-modbgn)/(segtim*SRATE); modbgn=modend; modend=0; T=segtim; segtim=7; SV3 L2+T 6 (modend-modbgn)/(segtim* SRATE); FIN;




Fig. 3b. Frequency modulation instrument implemented using functions.

PS1 1;ILN 500;PAC 1;SAM 25000; INS 0 1; com carrier frequency control; LSG V1 P5=P5/(P4*SRATE) B3; END; INS 0 2;com carrier amplitude control; LSG V3 P5=P5/(P4*SRATE) B4; END; INS 0 3;com modulation index control; LSG V5 P5=P5/(P4*SRATE) B5; END; INS 0 4;com sound production; MLT B3 2 B6; MLT B5 B6 B5; IOS B5 B6 B5 F1; AD2 B5 B3 B3; IOS B4 B3 B3 F1; OUT B3 B1; END; GEN 0 2 1 512 1 1;com sine; NOT 0 4 20; com to play all segments; frqbgn=HZ(440); frqend=HZ(880);segtim=4; (frequency control (INS 1)) SV3 0 1 frqbgn;com initl. V1; NOT 0 1 segtim frqend-frqbgn; frqbgn=frqend; frqend=HZ(660); segtim=3; NOT ? 1 segtim frqend-frqbgn; frqbgn=frqend; frqend=HZ(110); NOT ? 1 4 frqend-frqbgn; frqbgn=frqend; frqend=HZ(880); NOT ? 1 9 frqend-frqbgn; ampbgn=DB(54); ampend=DB(48); (amplitude control) SV3 0 3 ampbgn;com initl. V3 NOT 0 2 5 ampend-ampbgn; ampbgn=ampend; ampend=DB(60); NOT ? 2 7 ampend-ampbgn; ampbgn=ampend; ampend=DB(24); NOT ? 2 8 ampend-ampbgn; SV3 0 5 4;com initl. V5; (modulation index control (INS 3)) NOT 03 7 -4; NOT ? 3 6 8; NOT ? 3 7 -8; FIN;

Haynes 27



poser to overcome the stylistic limitations implied by the more obvious applications of the "note equals event" structure and provide a more supple means for controlling parameters. It is undoubtedly true that the structure of the general-purpose synthesis languages will tend to influence the beginner to think that notes represent discrete changes in one or more parameters at precise instants of time. This may not correspond to some current compositional techniques, notably those of composers such as lannis Xenakis, in which stationary sound parameters are all but banished. Once beyond the introductory stage, however, the inventive user will be surprised by the range of possibilities that exist for breaking away from the more obvious usages of the event list. This is made easier by the comparatively advanced score syntax in the IRCAM version of Music V.

Relative Structures in Music V

Earlier, it was shown how the Music V Pass 3 variables allow events to be controlled at the micro-note level. This can be extended if the variables are used to modify note parameters in one of the Pass 3 arithmetic modules (adders, multipliers, etc.), where they can apply global modifications that vary at a rate completely independent of the parameter changes in the note statements. Where global modi- fiers can be made to change at the beginning of notes, however, it is usually better to deal with them in Passes 1 and 2 using SV1 or SV2 statements. In his paper (1978), William Buxton describes the appropriateness of tree structures in music event lists, in which individual notes (terminal events) represent leaves that are defined as being relative to a particular branch. In such a scheme, note parameters are not absolute values but are subordinate to a global controller, and this means that modification of the global value will change all the dependent notes. In Music V (IRC) it is the named variables and relative variables (L and ?) that allow the user to create event lists in which parameters are presented in relative rather than absolute terms. Named and L variables can be used as

part of arithmetic expressions anywhere in the score, but they are particularly useful in the note list. Named variables can be used to name and store global values as reference points when one is cal- culating parameters for groups of notes. L variables refer to parameters in the immediately preceding score statement. The number following L indicates which parameter is involved, so that L5, for instance, can be used to refer to the fifth parameter of the preceding note. A ? placed in the action-time parameter (P2) has the effect of setting the action time such that the event begins when the preceding one ends. All three facilities, which are brought into play during the processing of the score by Pass 1, are used in the event list presented in Fig. 4. The example assumes that P5, which represents an amplitude controller, and P6, a frequency controller, will be converted from decibels and hertz respectively within the instrument definitions.

Three groups of notes are shown in Fig. 4. Group A, played by the first instrument, demonstrates how each note of a group can be related to its immediate predecessor in the score. This is quite natural in the case of the action times, represented by ? in all but the first note, but is somewhat more difficult to handle when applied to the amplitudes and pitches. The numbers (+3, +2, -4, +2) in the fifth parameter field representing successive changes in amplitude are fairly obvious, but the representa- tion of each pitch by means of its intervallic relationship to the immediately preceding note (whose pitch is preserved in L6) is rather more awkward. It does show how pure harmonic intervals can be represented, however, and had the relevant ratios been stored in named variables such as semitone, tone, fifth, they would have been easier to use. It is usually easier to relate amplitudes and pitches of notes to a common reference for the whole group by using named variables or Pass 2 G variables to store the relevant reference values.

Group B (in Fig. 4) is played by the second instrument, which is similar to the first except that, before being converted from decibels, P5 has the value stored in G1 added to it, and before being converted from hertz (in this case represented by note letter names), P6 is multiplied by G2. At the beginning of the group, G1 and G2 are set using an




Fig. 4. Music V score that demonstrates relative variables.

PS1 1; ILN 20; PAC 1; PS2 1; INS 0 1; OSC P5=DB P6=HZ B3 Fl; OUT B3 B1; END; INS 0 2; (Pass 2 variables control global amplitude & frequency) OSC P5=DB(P5+G1) P6=HZ(P6*G2) B3 F1; OUT B3 B1; END; GEN 021512 10.80.60.40.30.20.1 13; NOT 2 1 3 54 C; com Group A (INS 1); NOT ? 1 1 L5+3 L6*5/4; NOT ? 1 1.5 L5+2 L6*2/3; NOT ? 1 .5 L5-4 L6*9/8; NOT ? 1 2 L5+2 L6*13/12; time=2; dur= 1; amp= 54; frq=C; com Group B (INS 2); SV2 time 1 54 C;com set G1 & G2; NOT time 2 dtn*2 0 .5; NOT time+2 2 dtn*2 6 .25; NOT time+4 2 dtn -3 .25*D/C; NOT time+5 2 dtn 0 .25*G/C; NOT time+6 2 dtn*2 3 .5; SV2 1 54 1; DD= 1; com Group C (INS 2); NOT L2 2 DD*2 0 E/2; NOT ? 2 L4 1 G/2; NOT ? 2 DD/2 -1 F/2; NOT L2+1.5 2 DD*3 0 G/2; FIN; com terminate when last note has finished;

SV2 to 54 db (derived from amp) and middle C (derived from frq), and the numbers in P5 of the individual note statements represent values in decibels above or below the 54-db reference, while those in P6 show transpositions with respect to middle C. .5 and .25 represent pitches one and two octaves below it respectively, and .25*D/C is the D below the bass clef. One can represent equal-tem- pered interval ratios conveniently by dividing the relevant note letter names and, once again, this can be made more convenient if the ratios are placed in appropriately named variables (e.g., tritone = B/F). Successive action times are presented in P2 by values assigned in beats (i.e., seconds, unless the

metronome function has been reset) relative to the action time of the group (defined by time). Dura- tions are presented as multiples of a reference unit specified in dur (in this case set to 1).

Group C, which uses instrument 2, demonstrates a fairly economical way of specifying all the parameters. The action times are represented by ? except in the case of the last note, where it is desired to follow the preceding note after 1.5 beats irrespec- tive of its length (L2+1.5), and the durations are all related to a reference value defined by the variable DD. The amplitudes are represented as in Group B, but this time the stored frequency reference is not a named pitch but a number representing a transposi-

Haynes 29



tion factor (in this case 1) with respect to the notated pitches.

Text Macros

Since statements are sorted into time-ascending order in Pass 2 of Music V, gioups of notes of the sort shown in Fig. 4 can be placed in more or less any order in the score provided that the relevant reference parameters are correctly specified. The ? facility provides a convenient means of avoiding the need to specify absolute action times in P2, and its power is considerably enhanced by the RST and SIL commands, which allow the user to interpolate silences into the note list. This facility within Mu- sic V (IRC) to create relocatable note lists is potentially a very powerful structural aid. Unfor- tunately, it is at present necessary to type or at best copy with the editor the complete note group each time it appears. This is both tedious and untidy, and a facility for text repetition within the Music V syntax is now urgently needed. This would permit the user to define statement groups, preferably with the possibility of using arguments for the reference values. The group could then be invoked by name and followed by the assignment of reference values to the arguments so that the appropriate list of statements would be automatically generated and sent to Pass 2 for sorting with other such groups or separate statements explicitly presented by the user. The text macro is a familiar feature in computer operating systems; a design often encountered represents the dummy variables with % signs followed by a letter of the alphabet and possibly a default value. One possible syntax is to place the default value between angle brackets (e.g., (54)). When the macro is invoked its name is followed by a string of values that are assigned to the associated arguments during the expansion by the computer. In Fig. 4 Group C could be defined as a macro with the assignment of the SV2 statement and the variable DD rewritten as follows.

SV2 %A(1) %C(54) %D(1); DD=%B(1);

If given the name GRPC, it could be invoked by the statement "GRPC" alone, in which case all the ref-

erence values would assume their default values and generate a group identical to the stored copy. However, the statement "GRPC 10.5 66 2;" would start the group at beat 10, halve the durations, increase the reference amplitude to 66 db (amplifying the notes by 12 db) and transpose the pitches up- ward by one octave. Had it been desired to make note durations and action times independent so that in the example cited halving note durations would not alter the rhythm but merely shorten the notes, the action time parameter (P2) could have been given its own reference variable in place of the ? notation.

TT=%A(2); SV2 TT 1 %C(54)%D(1); DD=%B(1); NOT TT 2 DD*2 0 E/2; NOT TT+2 2 L4 1 G/2; NOT TT+2 2 DD/2 -1 F/2; ... etc.

The implementation of such a facility within the existing structure of Music V(IRC) would be prob- lematic, but the power it would offer the musician in structuring a score makes the provision of some sort of macro facility or at least a means of automatically repeating text a high priority if the language is to meet the needs of composers more fully.

An interesting possibility would be to produce a Music V compiler by taking a suitable language such as Pascal and building Music V syntax into it. The greatest benefit of this would be that the programming power inherent in the language would make the provision of new facilities much less difficult than is their incorporation into the present Fortran-based programs. Moreover, musicians would be provided with a more attractive and easily used language for writing their compositional subroutines.

Further Benefits of a Macro Facility

The macro has one important feature that can be very useful in designing music languages: the provision of default parameter values means that beginners can be screened easily from the more ad-




vanced and difficult to understand features of the language but can be gradually introduced to these features as users replace the default values with their own. This is why it is important that macro facilities be made available in all parts of the score and particularly within the instrument definitions. In this way a superstructure of macro commands could be built to provide frequently used procedures, beginners' modules, and a repertoire of standard compositional algorithms. This library could be updated to meet current needs, and users could build their own libraries of procedures used in their work. In this context, the present Music V syntax would provide the basic commands, which in most cases would be collected together in higher-level structures. These could then be made more compact and thus eliminate a frequent com- plaint, leveled at all the current general-purpose synthesis languages, that too much information must be typed. This need was recognized in the design of Music 360's orchestra translator, which includes facilities for defining macros made up of basic unit-generator calls. Predefined macros are not, however, built into the language as supplied to users, who must in general design their own according to the instructions in Chapter 3 of the "MUSIC 360 Reference Manual" (Vercoe 1973).

The grouping of commonly used structures in appropriately named macros can be an important means for protecting the inexperienced user from the low-level operations needed even for fairly common processes such as reverberation. The Music V instrument shown here is often used at IRCAM to provide reverberation. Its input (B6) is usually a pro- portion of the direct output of one or more sound- generating instruments. A number of RV1 and RV2 modules are used both parallel and in series, each requiring a reserved buffer in the Pass 3 variable array (V), which has a size in samples that corresponds to the required delay for that unit. The instrument parameters can be specified as absolute numbers, as shown in the example, but the modification of the delay constants poses quite a problem, since changing any buffer size in the V array with the exception of the last will mean that all the V address parameters must be changed. Furthermore, the instrument must be typed or at best copied into every score in which it is needed:

INS 0 50; com 4 RV1 units in parallel; RV1 B6 V300 V1100.827 B7; RV1 B6 V1101 V2001 .805 B8; RV1 B6 V2002 V3012 .783 B9; RV1 B6 V3013 V4134.764 B10; com RV1 units summed; AD4 B7 B8B9B10Bl11; com 3 RV2 units in series; RV2 Bl1 V4135 V4357 .7 .7 B12; RV2 B12 V4358 V4500.7 .7 B13; RV2 B13 V4501 V4813.7 .7 B14; com zeroize B6 so that samples don't accumulate; ZRB B6; OUT B14 B1; END;

This could be overcome by writing a relocatable structure in which the V locations are calculated internally relative to an initial address supplied by the user or by default.

IN=%A(6); BNR=%C(7); VNR=%D(300); PA=%E(.827); PB=%F(.805); PC=%G(.783); PD=%H(.764); DW=%I(800); DX=%J(900); DY=%K( 1010); DZ=%L(1121); DDX=%M(232); DDY=%N( 142); DDZ= % O(312); VVNR=VNR+DW+DX+DY+DZ+3; PPA=%P(.7); OUT=%Q(1);

INS 0 %R(50); (instrument number 50 by default) RV1 B(IN) V(VNR)

V(VNR+DW) PA B(BNR); RV1 B(IN) V(VNR+DW+1)

V(VNR+DW+ 1 +DX) PB B(BNR+1); RV1 B(IN) V(VNR+DW+DX+2)

V(VNR+DW+DX+2+DY) PC B(BNR+2); RV1 B(IN) V(VNR+DW+DX+DY+3)

V(VNR+DW+DX+DY+DZ+3) PD B(BNR+3); AD4 B(BNR) B(BNR+1) B(BNR+2)

B(BNR+3) B(BNR+4); RV2 B(BNR+4) V(VVNR)

V(VVNR+DDX) PPA PPA B(BNR+5); RV2 B(BNR+5) V(VVNR+DDX+1)

V(VVNR+DDX+DDY+ 1) PPA PPA B(BNR+6); RV2 B(BNR+6) V(VVNR+DDX+DDY+2)

V(VVNR+DDX+DDY+DDZ+2) PPA PPA B(BNR+7); ZRB B(IN); OUT B(BNR+7) B(BOUT); END;

Haynes 31



Even without the macro facility, represented by the %letter feature, the use of named variables (BNR, VNR, etc.) allows one to create a relocatable rever- berator that can already be incorporated into any Music V score at IRCAM. The possibility of placing the structure within a macro would mean, however, that the entire instrument might be invoked by placing a statement such as the following in the Music V score:

REVERB 3,,5,1000; com macro REVERB (IN=3, BNR= 5 & VNR= 1000);

Notice the use of two commas to represent the null field for %B, implying the default value of 1, and the fact that trailing commas for the other default parameters need not be represented. This means that it is generally more convenient to place the most frequently modified parameters at the head of the list. Of course, it is possible to create a similar facility by setting up a multiple-module unit in Pass 3, as has been done at IRCAM in the case of FM. This means expanding the size of Pass 3, however, which is the part of Music V that remains in memory for a significant amount of time, and there is no simple way to incorporate default values for parameters.

The need for a text-handling system in sound synthesis languages has been described in terms of the IRCAM version of Music V, but a facility of the kind proposed is just as much needed in other languages, most of which have far more rudimentary score structures than Music V(IRC). Of course the text macro is but one means of achieving this, and were the input language of a sound synthesis system to be implemented using a more versatile programming language such as Simula or Pascal, it should be easier to create an environment congenial to musicians. Computer users are familiar with macros, however, and the immense power of macros in allowing the setting up of default parameters has already been recognized by the designers of a number of music input languages. Indeed, both the EMS 1 and SYNTAL languages, which have been used with the PDP-15 computer-controlled analog synthesizer at the EMS Foundation in Stockholm, rely heavily on macros to generate the text repeti-

tions required to specify successive states of the synthesizer, and they also feature in the MUSYS III language (Grogono 1973) developed to control Peter Zinovieff's analog studio. The Stockholm languages do not have a separate event list. Expressed in terms of Music V it is as though the individual modules of the instrument definition have to ap- pear with a different parameter list each time a new note is to be played. The macro is crucial in reduc- ing the amount of text the user would otherwise be obliged to type. In EMS 1 recursive macro calls containing conditional expressions, which determine how the macro is to be expanded and when it is to be exited, offer a fairly practical means of specifying sound events that are analogous to the note statements in Music V. In the simple EMS1 score presented in Fig. 5a, four macros are defined by as- signing a name to a group of basic commands placed within double quotes. The purpose of the score is to produce a number of parallel ascending glissandi generated by the modules defined in the macro M1. This macro is nested within a higher- level macro (M2), which also contains the macro RELTID to adjust the action time (LT) and a conditional command,

IFPOS(VOCNR) VOCNR=VOCNR-1;FGEN=FGEN+1; ...,

which increments the frequency-parameter number for each successive voice until the specified maximum (VOCNR) is reached. Therefore M2 will be executed the number of times specified by the variable VOCNR, which is set in the highest-level macro (M3). This, in turn, is recursively called (i.e., repeated) the number of times specified by the variable REPNR. The control variables are set in a separate file, shown in Fig. 5b. Ten repetitions of an 18-voice glissando are requested, and the half-page score generates several pages of text when the macros are expanded.

Specification for a Macro Preprocessor for Music V

Earlier the need for more efficient and versatile text repetition facilities within the sound synthesis lan-




Fig. 5. Fig. 5a. EMS1 score. Fig. 5b. Control variables.

' * STANLEY HAYNES (11/8/74) - EMS 1 GLISSANDO EXPERIMENTS ***

NR 2.: PARALLEL ASCENDING GLISSANDI'

THE VALUES OF THE VARIABLES ARE TO BE INSERTED INTERACTIVELY' 1 /

RELTID ="IFUND(STICK)STICK=0; IFUND(TICK)TICK=0; IFUND(TACK)TACK=0; <TICK= TICK+TACK; IFPOS(TICK)SLASK= TICK/ 1000; STICK= STICK + SLASK; SLASK= SLASK* 1000; TICK =TICK- SLASK; <LT(STICK,TICK);" Ml ="FG(FGEN,0,0,WTYPE);FG(FGEN)> GLIS(FREQ 1,FREQ2,GLDUR,GLTYPE)> ENV(AMPL 1,AMPL2,GHALF,ENVTYP) >ENV(OLD,AMPL 1,GHALF,ENVTYP)> CHA( CHANNR, CHNAMP); " M2="IFPOS(VOCNR)VOCNR=VOCNR- 1 ;FGEN=FGEN+ 1;RELTID; LT(STICK, TICK); M1; M2; <" M3 ="IFPOS(REPNR)REPNR= REPNR- 1 ;FGEN= O; M2;M3; <" REPNR = REPNR; VOCNR= VOCNR; TACK= TACK; GLDUR = GLDUR; GLTYPE = GLTYPE; ENVTYP = ENVTYP; FREQ1 =FREQ 1;FREQ2= FREQ2;AMPL 1= AMPL1; AMPL2= AMPL2; CHANNR= CHANNR; CHNAMP = CHNAMP; GHALF = GLDUR/2; WTYPE= 1; WRITE('YEAR','MONTH','DAY','TIME'); WRITE('REPNR','VOCNR','GLDUR','TACK','GLTYPE','ENVTYP'); WRITE('CHANNR','CHNAMP','FREQ 1','FREQ2','AMPL 1','AMPL2'); M3;

*t* STANLEY HAYNES - DATA FILE 1 *A*

' THIS FILE ASSIGNS THE VARIABLES FOR (SHO3B)'

REPNR= 10; VOCNR= 18;GLTYPE= -4; ENVTYP =4;GLDUR= 15000;TACK= 500; FREQ1 = 1;FREQ2= 15999;AMPL1 = 10;AMPL2= 70; CHANNR= 1; CHNAMP= 100;

guages was discussed, and the text macro was proposed as a possible way of meeting this need. Macro features could be built into existing languages, but it might prove cumbersome to add such an intricate facility to an existing structure. New

languages ought perhaps to be designed with more sophisticated text-handling facilities included at the outset. The best way to enhance existing systems might be to supply them with a preprocessor that could function in a manner analogous to the

Haynes 33



relationship between the Music 10 sound synthesis language and Leland Smith's SCORE event-list preparation package. The addition of a preprocessor has the disadvantage of adding yet another pass over the data, but careful organization could reduce inconvenience to the user. Music V at IRCAM is already organized such that Pass 3 (the synthesis package) and PLAY (the program that converts the digital samples to sound) carn be called automatically from Passes 1 and 2 (the data preparation phase) if the appropriate control statements are included in the data. It would not be difficult to add a preprocessor to the chain and have it automatically call Passes 1 and 2 of Music V for instance. The design of such a processor is the subject of this section. Although it will be discussed in terms of the Music V system at IRCAM, the preprocessor could be adapted for use with other languages. The already sophisticated score-handling facilities in Music V(IRC) mean that the preprocessor need only concern itself with text expansion and parameter substitution, leaving the parameter conversions to be performed in Pass 1. For languages such as Music 4BF that have comparatively crude facilities in Passes 1 and 2, it might be better to organize the preprocessor so that it provides data for Pass 3 di- rectly. This would require that its design be considerably more intricate, however. A macro syntax providing facilities for the substitution of values for arguments in the macro call has already been described. An even more versatile macro facility is available in the MPX operating system recently introduced for use with the 3200 series computers manufactured by Systems Engineering Laboratories (SEL) of Florida. Here, the arguments within the macro definition are represented not by single letters of the alphabet but by variable names that are themselves the default values if the macro is called with the corresponding parameter missing. This means that one can vary the order of the parameters in the call without making changes to the body of the macro, since only the first line of the macro definition need be altered. This first line begins with the characters DEFM, followed by a space and the variable names in the order in which they are to be specified in the macro call. When one de- sires to change this order it is necessary merely to

change the order in the macro definition line. The parameters are referenced in the text of the macro by a % sign followed by the macro name. The process, which has much in common with the way parameters are passed to Fortran subroutines, is very flexible. For instance, the following macro written following these conventions could be used to pass frequency (FREQ), and amplitude (AMPL) parameters to a group of notes.

DEFM FREQ,AMPL NOT 0 1 1%AMPL %FREQ;(HZ(P5) con-

version in the instrument)

NOT 1 1 1%AMPL+3 %FREQ* 1.5; NOT 2 1 1 %AMPL-2 %FREQ*2; NOT 3 1 1 %AMPL+5 %FREQ*.75; ENDM

In the SEL system, the macro takes its name from the file in which it is stored, and were the example cited here to be placed in a file called GROUP, the macro call GROUP C,50 would cause the group to start on middle C with an amplitude of 1000. If ei- ther of the parameters were omitted from the call, the parameter name itself would be used with the value assigned to it higher in the score. For instance, if the macro call GROUP D were preceded in the score by the statement AMPL= 1500, the starting amplitude for the note group would be 1500.

The SEL macro definition language also includes conditional expressions that allow lines to be skipped according to whether individual parameters are present, absent, equal to, or not equal to a specified character string. This is achieved by means of forward branches to labels (beginning with % signs) that are placed on their own in the line preceding the block of text to which the branch is to be made. Unconditional branches may be made using such statements as GOTO % label. Although macro command files can be chained, it is not possible to nest them or set up internal counters, and this means that the recursive structures so useful in languages such as EMS1 cannot be used. The system is quite flexible, however, and in the following example, which consists of three three-note groups,




the choice of the second group would depend on whether the frequency was absent ((i)), present but not the pitch A ((ii)), or A itself ((iii)). Notice that at the end of the alternative second groups ((i) and (ii)) an unconditional branch to the third group is made by means of a GOTO statement. The macro definition is presented first, followed by the calling sequence, which sets up a default pitch (D) for the frequency parameter.

DEFM FREQAMPL (MACRO DEFINITION) DEFM FREQ,1AMPL

NOT 0 1 1 %AMPL %FREQ; (1st group) NOT 1 1I1%AMPL %FREQ*2; NOT 2 1 1%AMPL %FREQ* 1.5;

IFA % FREQ % LABELi (conditional IFT % FREQ NE A % LABELii expressions) IFT % FREQ EQ A % LABELiii % LABELi

NOT 3 1 1 %AMPL D; (i)(alternative 2nd groups) NOT 4 1 1 %AMPL D; NOT 5 1 1 %AMPL D;

GOTO % GROUP3 % LABELii

NOT 3 1 1 %AMPL % FREQ; (ii) NOT 4 1 1 %AMPL D; NOT 5 1 1 %AMPL A;

GOTO % GROUP3 % LABELiii

NOT 3 1 1 %AMPL FS; (iii) NOT 4 1 1 %AMPL E; NOT 5 1 1 %AMPL D;

% GROUP3 (3rd group) NOT 6 1 2 %AMPL E; NOT 8 1 1 %AMPL A; NOT 9 1 3 %AMPL D;

ENDM

FREQ=D; (CALLING SEQUENCE) AMPL= 2000;

GROUP A (for instance)

Although it might well benefit from the example provided by the macro-handling languages developed for computer operating systems, a text- generation facility for sound synthesis languages would probably need to be more sophisticated. In addition to having internal counters that could be generated and tested during the expansion of the

macro, it would be useful to be able to branch to labels earlier in the macro. Another useful feature would be the user's ability to specify in the macro call how many times the text is to be repeated and what arithmetic process is to control the evolution of the parameters. For instance, the call GROUP* 10 110* 1.5 66-3 might be used to request 10 repetitions of the macro quoted earlier, each one beginning a perfect fifth higher and 300 units lower in amplitude than the preceding one. Processes less linear in their evolution could be generated by nest- ing the repeated macros within one another, and the macro call OUTER 110*2 66-6 to the structure presented here would generate 9 repetitions of the group. These would be expanded as three groups of three, each one beginning an octave higher than its predecessor, with the initial notes of the individual groups ascending in fifths.

DEFM GRPFREQ,GRPAMPL ("OUTER") GROUP % GRPFRQ* 1.5 % GRPAMPL-300 ENDM

Still more intricate structures could be created by the combination of these procedures with the use of internally generated counters that could be used, for example, to modify the process after a specified number of repetitions.

Another function that might be performed by a macro processor for sound synthesis languages is the dynamic allocation of array space. This is already done to a limited extent in the IRCAM version of Music V, but the provision of macros would make such a facility even more essential. If part of a Music V instrument definition were implemented as a macro, the user would have to ensure that the P, G, V, F, and B array locations used were not unwittingly overwritten elsewhere in the score. In the REVERB macro presented earlier this was to a certain extent overcome by the identification of the array locations with symbolic names such as B(BNR) that could be set in the macro call, or by the use of array locations as named variables with assigned values. The most convenient solution, however, would be for the processor to allocate automatically array indices not already defined by the user, thus providing the

Haynes 35



choice as to whether the array areas used are to be explicitly defined. Often there is no need for the user to know precisely which array location is being used as long as the value stored in it is correctly retrieved. A good example is the association between the function number used by an oscillator and generated by a function generator, where as long as the correct linkage is maintained the user need not necessarily be aware of precisely which F- array is being used.

Hierarchically Organized Structures

Since macros that have already been defined can be stored in libraries and made available to all users, they can be used to shield beginners from the intri- cacies of the basic language commands and to provide higher-level structures for the more frequently used processes. However, although the languages used in the Stockholm studio are among those that rely most heavily on macros for text ma- nipulation, general-purpose macros have only been provided to control timing and certain simple arithmetic processes. It has been suggested that the prepackaging of procedures might produce stereo- typed music, and this is certainly something that must be guarded against, but a more likely explana- tion for the lack of these facilities is that with the exception of additive synthesis there are no particularly powerful synthesis models that can suitably be set up on Stockholm's analog synthesizer. Furthermore, the lack of structural separation between instrument-defining and event- controlling statements in EMS 1, for instance, makes the creation of hierarchical structural units more difficult. The availability of powerful synthesis models implemented using digital hardware must have been an important factor determining the design of the hierarchically structured language developed by William Buxton and his team at the University of Toronto. This is implemented in the context of the programming language C (Kernighan and Ritchie 1978) and allows control of a digital synthesizer by means of linked structures based on a fairly limited repertoire of sound synthesis models. Additive synthesis, frequency modulation,

nonlinear distortion (waveshaping) and VOSIM are provided.'

There are four main structural types in the Toronto system: those defining (1) scores, (2) objects (analogous to instrument definitions), (3) functions, and (4) waveforms. Each of these may be specified by means of commands issued using an interactive graphics package, which has many facilities for automatically correcting beginners' mis- takes. The setting up of functions, which may be used to specify envelopes and waveforms, is not un- like the segmental approach employed in the GEN 1 function-generating routine in Music V, but since the synthesis structures are prepackaged, the definition of objects is comparatively simple, and consists of tags associating the object variables with parameters produced in the event list. The score structures are perhaps the most interesting, since they allow hierarchically organized scores to be specified conveniently.

A score file begins with a score structure that contains the name of the file and the score's identi- fying number as well as its duration; the number of events it contains; pointers to the beginning and end of the event list; and global parameters specifying the dynamic variation, tempo variation, and entry-delay variation. The last three are references to predefined functions, created by function structures, which control the global tempo, dynamics, and articulation of the score. There are two types of musical events available at present: the note event and the score event. The former is similar to a Mu- sic V NOTE, except that action time is specified by means of pointers to the previous and following events, and duration is specified both as an entry- delay before the next event and as the duration of the current one. If the latter is smaller than the former a rest will result. Other parameters specify the amplitude, the frequency, and the waveform func-

1. VOSIM is based on the development by Kaegi and Tempelaars at the Institute for Sonology in Utrecht (1978) of a synthesis method in which sin2 pulses are repeated, separated by delays of varying length. The ratio of the pulse width to the length of the cycle before the next pulse determines the spectrum produced, and by dynamically varying this ratio during a note various diph- thonglike transitions can be produced.




tion to be used. The score event has the same pointers to the previous and following events and the same entry-delay parameter, but the amplitude and pitch parameters refer to global qualities of a subscore and function as transpositions. Other parameters determine which subscore is to be accessed and whether the time-factor is to affect the entry-delay, the duration, or both. The time- factor is itself specified as an augmentation or diminution of the subscore times. A change in the global frequency, volume, and time scalers will modify all of the dependent musical events.

The Toronto system makes it very easy to create treelike structures in which the parameters of the lowest-level units, the note events, can be altered radically by changes in the parameters of the superstructure. The double-linked event list, in which events are related to both those preceding and following them, provides a structure that can be edited easily; events can be added and removed at will. Since these events can be single notes or sub- scores, the musician is provided with a convenient environment for manipulating elements of his or her score, which can be displayed using the built-in graphics facilities. Buxton, however, does not make it clear in his paper "Design Issues in the Founda- tion of a Computer-based Tool for Musical Com- position" (1978) to what extent the hierarchical structure can be made to extend beyond the note event to the micronote level to deal with situations such as the one described in relation to the SV3 statement in Music V, in which it is desired to make control parameters temporally independent of one another. Perhaps an even more basic event type is needed that will affect only a single sound parameter. The present note event would then be a special case in which all the parameters change at the same instant.

Composers are becoming more and more inter- ested in the exercise of control over the evolution of timbre in their pieces. A work such as Karlheinz Stockhausen's Stimmung for six voices is interesting partly because of the interplay of vowels sung on notes of the same chord (the second, third, fourth, fifth, and seventh partials of a low B flat) that is sustained throughout the hour-long piece. The provision of a means of independently control-

ling sound parameters seems to be an important requirement in new systems.

Controlling Micro Note Events

A common way of handling micronote events, which is available in all of the general-purpose synthesis languages and in the Toronto system, is to define the entire structure containing the overlapping parameter changes as a single note, with the evolution of the parameters controlled by predefined, stored functions created using segmental function generators (such as Function Generator 1 [GEN1] in Music V). Their usefulness to the musician depends on the extent to which the values required to set the segments relate to those in which he or she thinks. At Toronto the functions can be drawn by hand at a graphics terminal, the best method provided that the function is not too complex and that absolute accuracy is not necessary.

GEN 1 in Music V(IRC) is a good example of a structure that is not very convenient, since although the y axis (the varying value) can be specified freely by the user and is normalized automatically to between 0 and +1, the x (or time) axis must always be specified in terms of a number of array elements that is a multiple of 32. It is generally convenient for a musician to think in beats (which may or may not be 1 sec long). If a sound complex lasts 77 beats, for example, the arithmetic necessary to scale it within the nearest allowed function size of 64 would be quite taxing. Further- more, since changes can only take place on the beat, the noninteger values for x would have to be truncated. Fortunately, an additional function-generating routine (GEN 31) has been provided at IRCAM so that the number of steps specified when one is defining the function is automatically normalized so as to place it within the required number of locations. This means that, provided a step is chosen that is equal to the smallest common denominator of x-axis values, the time structure (i.e., the x axis or abscissa) can be notated freely in terms of these steps.

Haynes 37



GEN 0 31 1 512 0,0 DB(66),20 DB(60),30 DB(48),40 DB(51),43 DB(46),47 DB(54),60 DB(50),80 DB(45),100 DB(30),150 0,200

The values can be specified in terms of decibels or hertz and will be normalized into their correct relationship between 0 and 1. To extract the appropriate values as specified in the preceding function definition, it is simply necessary to present the oscillator playing it with an amplitude parameter equal to the greatest value in the function (DB(66) in this case), and a lower or higher setting will scale the values proportionally. The abscissa represent subdivisions of 200 scaled according to the length of the note, and if this is 2 sec, for instance, the steps will be 0.01 sec long and the maximum value (66 db) reached 0.2 sec after the beginning. GENs 1 and 31 join the specified points by linear interpola- tion, but for amplitude and frequency variation exponential segments are more appropriate. These can be produced in the IRCAM version of Music V by using GEN 9, which has the same parameters as GEN 1, but there is not yet an exponential version of GEN 31. Control of the varying parameters by means of stored functions can be quite convenient for medium-length structures but can be cumbersome when there are a large number of segments. Although the calculation of functions is quite a time-consuming process for the computer, functions are particularly convenient in situations where they can be used more than once.

Real-Time Languages

The language structure for control of the Toronto system can be kept comparatively simple because the sound-generating instruments are prepackaged. As has already been mentioned, this simplification means that one of the principal attractions of computer sound synthesis, the possibility of setting up individually designed sound-generating structures, is lost. Buxton justified the lack of generality by the increased "strength" of the system in terms of its ease of use by technologically unsophisticated musicians, but in general it will be neither possible nor desirable to limit instrument structures in future

systems. This does not mean that the Toronto example is not useful, but that it might be necessary to extend its facilities to take into account more sophisticated object structures. Many of the new systems will, like the one at Toronto, be based on digital synthesizers, which are rapidly becoming the most cost-effective means of implementing sound synthesis. Some will be designed to operate in real-time, which makes extreme demands on an operating system.

Perhaps the most advanced digital synthesizers to be designed to date are the 4C and 4X Machines designed by Peppino di Giugno of IRCAM. The 4C operates as a parallel-processing 24-bit computer optimized for those operations required for sound synthesis. It can be interfaced to any suitable mini- computer but is currently being used mostly with PDP-11/34 and LS 1-11 processors. The basic building block of the 4C is not the oscillator but the adders and multipliers that can be assembled to create oscillators, filters, envelope-followers and other sound-processing modules. This offers the user a versatile system for creating modules, but a correspondingly sophisticated specification language is required to define instruments, functions, and the event list. The latter is complicated by the need for real-time inputs (which include a bank of 32 faders and joystick controls) to modify stored values in real-time and be themselves stored for subsequent use. Thus a final "performance" can be prepared in stages whose performance characteris- tics can be saved or subsequently modified in a manner somewhat analogous to the way a conduc- tor rehearses an orchestra. A prototype for such an operating system is GROOVE, which was developed at Bell Laboratories in New Jersey to control a small analog synthesizer furnished with a variety of joystick, slider, and other controls (Mathews and Moore 1970). The system was dismantled at the end of 1979 but nevertheless offers an example of musician-machine interaction that is still unsurpassed.

GROOVE was developed by M. V. Mathews and F. R. Moore for Bell Laboratories' Honeywell DDP-224 computer and was designed to compose and edit functions of time in real-time. The functions were converted into voltages that could be




used to control mechanical, visual, or audio processes, but the system was mostly used with a specially constructed analog sound synthesizer. The functions were edited and stored in disk files and could be combined with one another and with real-time voltage inputs derived from devices such as knobs, sliders, and keyboards. Periodic functions could be generated and combined with the other functions and displayed on the system oscilloscope, which could also be used to show the current value of the time pointer, whose speed and direction when scanning the abscissa of the functions could be controlled manually. Up to 40 simultaneous functions could be operated upon in real-time and combined to form the 14 output voltages to control the synthesizer. The digital sampling rate of the system could be extended to about 200 Hz, and it was possible for a user to write his or her own sub- routine to extend the facilities of the language; unfortunately, this had to be coded in the DDP-224 assembly language.

The system allowed the user to modify individual parameters independently of one another. It was possible to listen to a partially complete score and gradually refine its interpretation in the manner that a piece for human performers might be re- hearsed. Since the functions were continuously variable with respect to time, and the whole process was highly interactive, there was great scope for the expression of nuances associated with instrumental performance that are often so difficult to incorporate into electronic pieces. GROOVE was used to realize a movement from Ravel's String Quartet. The varied interpretations created by a number of different musicians demonstrate the flexibility of the system. Perhaps most signifi- cantly, GROOVE overcame the rigidity that can be such a problem in sound synthesis systems based on processors that do not operate in real-time. Moreover, the manual interaction was sensibly organized such that the stored functions could be corrected subsequently and replayed at a continuously varying tempo, so that a user's performance need not be too limited by a lack of manual dexterity.

Although GROOVE provides a good example of what can be achieved in musician-machine interac-

tion, the stored-function principle cannot readily be used to control devices such as the 4C synthesizer in which a vastly increased number of output functions would be needed for the many parameters involved. In fact, the demands made are so great that hardware ramp generators have been incorporated in the synthesizer's design so that glissandi and amplitude envelopes can be initiated by the controlling computer but executed in hardware. This greatly relieves the burden on the computer, since the control sampling rate is determined by the frequency of the breakpoints rather than by the individual steps in continuously varying functions. Furthermore, the curves can be made smoother because it is convenient to implement them at the higher internal sampling rate of the synthesizer. The 4C may typically be controlled by a PDP-11/34 or LS 1-11 processor equipped with a small hard disk or even floppy disks. Communication is via a buffer containing the synthesizer's control parameters and commands determining the interconnec- tion of its basic modules.

Of the programs that have been written to control the 4C, Curtis Abbott's 4CED is probably the most comprehensive. This program allows the patching of the synthesizer to be specified in a manner similar to the definition of instruments in the general-purpose synthesis languages. There are also commands to load wavetables, attach poten- tiometers to registers, and compile sequences. The sequences, which can be used to define envelope breakpoints or to create an event list, can be cycled and triggered or stop one another. They can also trigger command lists, and since these may contain any of 4CED's basic commands, including those making or breaking connections between patches and instruments, there is considerable scope for real-time control. A particularly useful feature is that the precise registers used when a patch is loaded can be passed as parameters, and it is possible to apply a subpatch within a patch definition. This has made it possible to provide a library of higher-level modules that can be incorporated in instrument definitions just as if they existed as basic units in the synthesizer. As a debugging aid a set of commands have been provided to display patch in- terconnections, and register values and many other

Haynes 39



details relevant to the state of the system. It is also possible to write register settings to a disk file. These can later be reconstituted to make a function specification that imitates the movement of a po- tentiometer, for example.

The provision of sophisticated language facilities in real-time makes heavy demands on the PDP-11/34 processor and its RT-11 operating system under which 4CED runs. It is important to make sure that sufficient time is allowed for the computer to complete its calculations, and it must be borne in mind that the loading of patches and wavetables takes a finite amount of time that varies according to what else is going on. The 64-Kbyte user address space of the PDP-11 imposes limitations on the length of sequences that may be played, although one can overcome this by dividing a score into several smaller sequences and reading one sequence into one-half of the memory available while the other half is playing. Ideally, the system should be provided with a more powerful processor but, provided that the timing requirements are not too stringent, the combination of a typed score with the possibility of manual modification while it is playing makes this a powerful medium for de- veloping musical ideas.

Music Input Systems

The synthesis systems described so far are by and large independent of the means available for alter- ing musical information. In many systems the file containing the score can be input in a variety of formats that are then processed by the appropriate programs, running as free-standing packages. In the case of Music 11 at M.I.T., a graphics package, NEDIT, allows the user to input common musical notation and edit the score. Results of the operation are displayed on a visual display unit. Similar facilities are available at Toronto, and in both centers other input styles such as piano-roll notation (use of lines to display the evolution of frequency and other parameters with respect to time) are available for composers who wish to notate more continuously evolving processes than can readily be expressed using conventional notation. Graphics

systems are attractive and can be used intuitively, but of course they provide no opportunity to pre- pare information away from the system. Input languages using alphanumeric information can be prepared easily on any teletype equipped with a paper tape punch, and then quickly input into the main sound synthesis system. Since graphic display systems, particularly those equipped with refresh screens, are comparatively expensive, the number of musicians who could simultaneously work with an interactive music display is likely to be restricted. For this reason typed alphanumeric input systems are used by a number of languages, including Leland Smith's SCORE and Giovanni de Poli's MUSICA. The former, designed for use with Music 10, is the more general and incorporates some compositional facilities. SCORE requires that the user submit separate lists for each parameter that show the changing values for successive notes. MUSICA is more closely tied to common musical notation and represents each symbol with a string of characters or digits as appropriate. MUSICA was developed at the University of Padua and has been adapted at IRCAM to provide input for Music V in the form of time, duration, and amplitude parameters. There are special symbols for clefs and key signatures, and notes are represented by letter names preceded by the signs # and & for sharp and flat respectively. Octave transpositions above the octave beginning with middle C are represented by apostrophes, and those below by commas preceding the note letter. Durations are represented by numbers, with 1 representing a whole note, 4 a quarter note, and so on. There are also symbols that represent slurs, expression marks (such as accents, fermata and staccati), and phrasing signs. The example in Fig. 6 demonstrates that MUSICA provides a compact method for encoding con- ventionally notated music, but it can be a little difficult to read until one becomes accustomed to it. The same fragment, from the opening of the Brit- ish national anthem, has also been encoded using SCORE, for comparison. The format employed in MUSICA has the advantage over that employed in SCORE in that the tempo and pitch identifiers can be kept together in a compact form, which is not difficult to memorize once the basic codes are




Fig. 6. Phrase from the Brit- ish national anthem encoded using MUSICA, SCORE, and common musical notation.

MUSICA INSi, 1,1, $ F3:4$

4'GS G A/4. 'F 8'G 4'A/

SCORE INS1 0,6 P2 RHY/4///4./8/4; P3 NOTES/G4//A4/FS/G/A; P4 "F"; END;

known. The characters between the $ signs represent the key and time signatures, and the constant dynamic level (forte) is indicated by the "S" placed after the first note. MUSICA, however, has none of the facilities provided in SCORE for notating the more continuously evolving phenomena associated with contemporary and especially electronic music. Although in its present form MUSICA provides a neat means of encoding conventional music for computer analysis, it would take considerable development to make it really useful as a general language for computer-synthesized music.

Conclusion

The use of the computer for the synthesis of electronic music has three principal advantages: high sound quality, precise control of the parameters, and an ordered data structure. The benefits of high sound quality are obvious, and it is certainly a relief to be free from the instability of analog oscillators. The precision with which sounds may be specified brings a new dimension to electronic music realized using the computer. It is now possible to imitate natural sounds with great accuracy and then modify the synthesis parameters to produce new but related ones. Furthermore, the precise control of frequency and amplitude needed for techniques such as FM is all but impossible with most analog equipment, and since computer-synthesized sounds must be specified exactly in whatever language is being used, they can easily be repeated. A frequently encountered problem in analog studios is that complicated patches may be

Common Musical Notation

f

difficult to set up when needed; use of the computer makes it possible to run the same data over and over again, making small modifications as necessary. Since the parameter changes may be made at rates as fast as the acoustic sampling rate, which may be in excess of 20,000 samples per second, the composer is not limited by manual dexterity.

The computer is potentially capable of synthesiz- ing any sound. A major limitation of current systems using the general-purpose synthesis languages is that sound cannot usually be generated in real-time. This means that it is not possible to influence the process interactively using manual controls. Parameter settings must be estimated and initial test runs resubmitted after preliminary hear- ings. Indeed, many such runs may be needed to tune the parameters of a complex sound sequence. To overcome this limitation a number of real-time systems using digital synthesizers controlled by comparatively small computers are currently being developed. Although somewhat limited by the analog synthesizer with which it was used, the GROOVE system at Bell Laboratories has shown what can be achieved when fully interactive operation is available and signals from real-time controls can be stored and edited. The 4C synthesizer at IR- CAM in Paris allows a score to be prepared in a language somewhat akin to the general-purpose languages, but this can be modified in performance using real-time signals derived from devices such as knobs, faders, and keyboards, which can also be stored in disk files for subsequent editing. A final tape can thus be built up in stages; if necessary one parameter can be modified at a time. Alternatively, the final realization can be left for the concert plat-

Haynes 41



form, where the operator can respond to other performers and so overcome the inflexibility characteristic of many works for live performers and tape.

The 4C system's ability to process sounds from microphones or from a prerecorded tape is also a feature of the most recent versions of the general- purpose languages. This can extend the composer's sound palette considerably, since the richness of such material can provide a good basis for subtrac- tive synthesis or it can be used as a source of control signals that vary in a realistic manner. In real-time systems it may even be possible to adapt conventional instruments so that they can be used as a highly responsive source of control signals. The use of general purpose languages often makes it easier to produce a richly varied sound by processing a recorded model than by estimating the parameters needed to create it synthetically. The new facilities in the IRCAM version of Music V used to specify at which rate portions of an input sound file are to be read, and the flexibility with which the extracts may be positioned and superim- posed in the output file, makes this an excellent medium for the creation of musique concrete. Al- ready these techniques have been exploited in York

H611er's Arcus for 17 instruments and quadraphonic tape, realized at IRCAM during the summer of 1978 (Haynes 1978), and in Jean-Claude Risset's Songes, a quadraphonic tape piece completed in 1979. There is considerable scope for the multiply- ing of a small amount of source material to produce an extended piece, perhaps in the manner of Pierre Henry's classic Variations on a Door and a Sigh, created using more conventional musique concrete techniques. Indeed, the realization of Arcus, which involved a considerable quantity of prerecorded material, suggests that the comparatively low through- put of systems using the general-purpose languages makes it more efficient to use them to multiply a fairly limited amount of source material.

Whether using the computer for synthesis, sound processing, or both, the composer needs a grasp of musical acoustics, a fertile imagination, and a certain amount of patience. It is a common fallacy that an extensive knowledge of computing is

needed, but the mechanics of using the computer and the basic principles of the sound synthesis languages are fairly quickly learned. What is much more difficult to develop is the ability to express imagined sounds in terms of the instrument design and parameters needed for their synthesis. This comes with study of the acoustic principles involved and with experience, which is why courses in musical acoustics should be made an important part of a musician's training. Such an understand- ing could benefit instrumental and vocal composition as well as future work in the medium of electroacoustic music. The new real-time systems should shorten the trial-and-error period needed to establish the correct sound synthesis parameters. Much has already been achieved using the existing general-purpose languages. One benefit of the ordered data structure required by the computer is that scores can be archived and made available to other composers, who can modify them for use in their own pieces or use them as examples of the syntax involved. The archiving of data for general use at institutions devoted to computer music synthesis is very important, and Risset's "Introductory Catalog of Computer-synthesized Sounds" (Risset 1969), with its presentation of Music V data and its accompanying recording, is an example that should be emulated more than it has been hitherto.

Despite improvements in computer music facilities that make them more accessible to musicians without specialized training, it would be unwise to predict that, unassisted, a composer new to the medium would be likely to produce a piece that uses the computer completely effectively. Years of training are required to learn to play instruments such as the violin or piano, and composers must have some knowledge of the performance techniques involved even if they cannot actually play the instruments they are writing for. If a composer lacks the necessary training and experience to realize a piece, an experienced assistant can help the composer to realize his or her intentions more ade- quately than would be the case had he or she been left to experiment blindly. The composer who in- tends to continue to use the computer in the future, however, should probably receive tuition as




part of the assistance provided, so that he or she can gradually become independent of the assistant and work independently. It seems likely that the truly significant computer-synthesized pieces will be created by musicians who combine talent as composers with a refined appreciation of acoustics and the computer medium. This has certainly been true during the first decade of serious work in this field, which has produced characteristic pieces using both simple and sophisticated systems. Im- provements of the systems alone will not bring about the production of better music; Stock- hausen's Kontakte will forever stand as testimony to the possibility of creating a masterpiece with comparatively unsophisticated technology. It is not so much the lack of equipment in the digital sound studio as the composer's imagination and ability which is the limiting factor. Yet it is important that the composer be given as much help as possible through the provision of adaptable and congenial operating systems.

With digital sound synthesis compositional control may be exercised over a multiplicity of parameters that are already assumed in composing for conventional instruments. This offers the composer great power to create new sounds, but data reduction techniques are likely to become in- creasingly important if computer scores are not to become unwieldy. A macro preprocessor for existing general-purpose languages has been described, and S. R. Holtzman (1980) and others have been working on generative grammars that should help composers express their ideas in a more compact form. An immense advantage of macro structures is that commonly needed procedures can be prepackaged so that they can be used with default parameters by beginners or assigned specific values by more sophisticated users. Such structures should be built into the new languages being developed for real-time systems. They must also be provided at centers where existing general-purpose languages are used, to relieve the composer of the typing of any more data than is absolutely necessary.

Despite the power of digital sound synthesis, it must be admitted that there has not yet been a large body of music created using the medium.

Composers such as Jean-Claude Risset in France and John Chowning in the United States have shown what richness of timbre can be achieved, but few of the better-known composers of the post- World War II era have yet ventured into the computer music studios. This may be due partly to their fear that they might be used as "guinea pigs." Some may have been discouraged by weaknesses in the design of the musician-machine interface in many of the systems. The literature on digital synthesis advertises its potential for creating any sound imag- inable, but composers must remember that this is limited in practice by the power of the hardware and by their ability to express sounds in terms of synthesis parameters. This depends on the composer's experience and on the design of the computer languages. Newer ones, such as the IR- CAM version of Music V, or Music 11 at M.I.T., have given this matter much more attention, but there is considerable scope for improvement. In particular, some application of artificial intelligence (AI) to the problem of data reduction should help bring about a situation where the computer will not usurp the composer but provide him or her with a flexible means for working out new ideas. This, coupled with powerful synthesis facilities and used by composers aware of the medium's true potential, should at last produce works that will justify the enormous resources available to the musicians of our era.

References

Buxton, W. 1978. "Design Issues in the Foundation of a Computer-based Tool for Musical Composition." Tech- nical Report CSRG-97. Toronto: University of Toronto.

Grogono, P. 1973. "MUSYS-Software for Electronic Mu- sic Studio." Software Practice and Experience October/ December.

Haynes, S. 1978. "Report on the Realization of York H61- ler's ARCUS." IRCAM Report. Paris: IRCAM.

Holtzman, S. 1980. "GGDL Manual." Computer Science Department Report CSR-56-80. Edinburgh: Edinburgh University.

Kaegi, W., and Tempelaars, S. 1978. "VOSIM-A New

Haynes 43



Sound Synthesis System." Journal of the Audio Engi- neering Society 26(6) :418-425.

Kernighan, B., and Ritchie, D. 1978. The C Programming Language. Englewood Cliffs, New Jersey: Prentice-Hall.

Mathews, M., and Moore, F. R. 1970. "GROOVE-A Pro- gram to Compose, Store, and Edit Functions of Time." Communications of the ACM 13(12): 715-721.

Risset, J.-C. 1969. "An Introductory Catalog of Computer- synthesized Sounds." Murray Hill, New Jersey: Bell Laboratories.

Smith, L. 1972. "SCORE-A Musician's Approach to Computer Music." Journal of the Audio Engineering Society 20(1): 7-14.

Vercoe, B. 1973. "MUSIC 360 Reference Manual." Cambridge, Massachusetts: M.I.T. Experimental Music Studio.

Vercoe, B. 1980. "Music 11 Reference Manual." Cambridge, Massachusetts: M.I.T. Experimental Music Studio.




the musician-machine interface in digital sound synthesis

Documents