Scot: A Score Translator for Music 11

by Michael David Good

Submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor of Science at the Massachusetts Institute of Technology, June, 1979

Department of Electrical Engineering and Computer Science
May 23, 1979

Supervised by Marvin Minsky, Ph.D.
Donner Professor of Science in the Department of Electrical Engineering and Computer Science

Copyright © 1979 by Michael Good. All rights reserved.

Abstract

The problem of entering musical scores into a computer in a simple, error-resistant manner has been dealt with by several projects.  Most of these have used the computer as a tool for musicological work or for printing music.  Scot is a language for entering musical scores into a computer for synthesis.  Much of its syntax is derived from ALMA, an Alphameric Language for Music Analysis developed by Murray Gould and George Logemann, modified to meet the demands of the composer instead of the analyst.

Scot serves as a preprocessor for the Music 11 system developed at the Experimental Music Studio of the Massachusetts Institute of Technology.  The Scot compiler produces a Music 11 score, which may then be synthesized in conjunction with a Music 11 orchestra.  Scot is implemented by a YACC specification file that produces a C program.  This implementation enables changes and extensions to be made easily.

Historical Background

In the 1960’s, many possible applications of computers to musical problems were being considered.  Among these problems were the automated printing of music, various musicological problems such as indexing and bibliography, electronic music synthesis, and computer composition.  All of these applications concern themselves to some extent with the specification of musical scores in a format that can be handled by a computer.

The DARMS (Digital Alternate Representation of Musical Scores) project, led by Stefan Bauer-Mengelberg, is one of the most well-known projects dealing with automated music printing [Bauer-Mengelberg 1970; Erickson 1977].  DARMS was viewed as a language which could be used by an optical scanner to produce printed versions of a musical score.  Alternatively, in the absence of these scanners, a clerk without musical training would be able to input a musical score using DARMS.  It is aimed at representing the graphical element of a musical score: for example, staff lines and spaces are assigned numerical values ranging from 0 (ten ledger lines below the staff) to 49 (ten ledger lines above the staff).  This graphical outlook contrasts with most of the languages designed for use in other areas.

Input languages for musical analysis followed another path.  Many of these languages are presented in summary in [Brook 1970b].  One of the simplest languages was the Plaine and Easie Code developed by Barry S. Brook [Brook 1970a].  Designed for use in areas like thematic cataloguing, the Code represents notes with the letters A through G, durations with single digits, accidentals by # or b, bar lines by /, and octave placement by commas and apostrophes.  ALMA, an Alphameric Language for Music Analysis, was a greatly expanded and modified version of the Plaine and Easie Code [Gould and Logemann 1970].

Languages used to specify scores to be synthesized by a computer have generally been much closer to machine representation than to traditional music notation.  One of the earliest of these languages was MUSIC IV, developed at Bell Laboratories [Mathews 1961].  Other examples from the 1960’s include MUSIGOL [MacInnis 1968], MUSIC V [Mathews 1969], and MUSIC 360 [Vercoe 1973].  The Music 11 language developed at the MIT Experimental Music Studio is a direct descendant of MUSIC 360 [Vercoe 1978]. Languages such as SCORE [Smith 1972] and Scriptu [Brown 1977] are closer to standard notation, but are still machine oriented.  Scot and its immediate predecessor, SOGO [Howe 1978], attempt to take the syntax of ALMA and adapt it to compositional purposes.  This is done both by adding new features and by removing those features that serve purely musicological functions.  Both of these languages produce the lower-level Music 11 score file as output.

Programming computers to compose musical scores has been investigated by Lejaren Hiller and other composers [Hiller and Isaacson 1959; Hiller and Baker 1965].  In this area, computer programs produce, but do not necessarily perform, musical compositions.  The language problem here is that of providing an output notation for humans, rather than an input language for the computer, and is outside the scope of this paper.

Summary of Music 11

In order to understand how Scot enables a score to be synthesized, it is necessary to present some information about the Music 11 system on which it is based.  The basic concepts of computer sound synthesis will not be presented here.  The interested reader may refer to [Rogers 1975].  Many of the features of the MUSIC 360 language described there are also present in Music 11.

To synthesize a composition in the Music 11 system, two files are required–an orchestra and a score.  The orchestra is the actual sound-producing program, while the score contains data that drives the orchestra program.

An orchestra consists of one or more instruments that are built from basic blocks such as oscillators, envelope generators, and filters.  At MIT, a collection of previously built “canned” instruments is available to the composer by using the orchestra archiver program.  However, the orchestra archiver is an addition to the Music 11 system, not a part of the general system available outside the Studio.

The score contains the data necessary to drive the orchestra, and it is this file that is produced as output from Scot.  Data contained in the score includes definitions of stored function tables, tempo control statements, and specification of the notes.  All statements are contained on one line.

Stored function tables contain data such as waveforms for oscillators and attack shapes for envelopes.  They are defined by function statements beginning with “f”.  For example, the statement “f1 0 256 10 2 0 1” would define function #1, represented by a 256 place table created at time 0.  The “10” refers to generation routine #10, the sine wave generator.  The remaining numbers are defined by the specific generation routine; in this case, the result is a waveform whose fundamental is twice as strong as its third harmonic.

A score may contain one or more sections.  The end of a section is noted by a statement starting with “s”.  Each section may contain one tempo statement, starting with “t” and then alternating score times and metronome markings for those times.  For example, “t0 60 6 60 6 80 10 60” specifies a tempo of 60 at beat 0, 80 at beat 6, and a linear ritardando to a tempo of 60 at beat 10.  All of these score times are relative to the start of the score section, not the start of the entire score.  Tempos do not carry across score sections; any score section not containing a tempo statement defaults to “t0 60”.

Notes are specified by note statements beginning with “i”.  The first parameter (P1) refers to the instrument number as defined within an orchestra.  P2 refers to the starting time of the note in beats, while P3 refers to the duration of the note in beats.  The meaning of the remaining parameters is specified by the orchestral instrument.  However, a common convention is that P4 contains information regarding slurs, while P5 contains pitch information.  These conventions are not enforced by Music 11, but are required by Scot.  The pitch may be represented in several ways.  Scot used octave pitch class (PCH) notation, where the integer part of a number refers to the octave while the fractional part refers to one of the twelve equal tempered pitch classes.  Middle C is represented by 8.00, the C above by 9.00, the F above that by 9.05, etc.  Thus the statement “i1 0 4 0 8.11” refers to a note played by instrument #1, starting at time 0 and lasting for 4 beats, playing the B above middle C.

With this information, the reader should be able to understand the score generation done by Scot.  Readers desiring more information should consult the Music 11 Reference Manual [Vercoe 1978].  For less detailed information and an explanation of the conventions for note statements, the Quick Introduction may be more useful [Gold 1978].

The Scot Language

Overview

Scot is a musical input language designed for synthesis of scores written in more-or-less traditional music notation.  The language has a well-defined syntax which can be represented in Backus-Naur Form, following the example of ALGOL 60 [Naur 1963].  This section may serve as a reference manual for Scot.  The syntax of each element of a Scot score is presented along with a semantic description of the element.  Examples are included as needed.

Basic symbols

Syntax:

<instrument name>	::=	<$ followed immediately by a token>
<token>	::=	<upper or lower case letter> |
		<digit> |
		_ |
		<token> <upper or lower case letter> |
		<token> <digit> |
		<token> _
<integer>	::=	<digit> |
		<integer> <digit>
<key>	::=	<any string matching “key” for at least
		one letter>
<time>	::=	<any string matching “time” for at least
		two letters>
<transpose>	::=	<any string matching “transpose” for at
		least two letters>
<accidentals>	::=	<any string matching “accidentals” for
		at least one letter>
<octaves>	::=	<any string matching “octaves” for at
		least one letter>
<comment>	::=	; <any string not including a new line
		character>

Semantics:

These are the basic symbols of the Scot language.  They are symbols that are recognized by the lexical analyzer, rather than by the parser.  In the case of <comment>s, the lexical analyzer screens and discards all characters following the semicolon and preceding the next new line character.  Notice that abbreviations of <time> and <transpose> must be at least two characters long, as “t” would be ambiguous.

Scot score

Syntax:

<Scot score> ::= <orchestra> <body> end

Semantics:

A Scot score consists of an <orchestra> and a <body> made up of function and score sections, followed by the delimiter “end”.  Each of these component elements will be discussed separately.

Orchestra

Syntax:

<orchestra>	::=	orchestra { <token list> }
<token list>	::=	<token> |
		<token list> <token>

Semantics:

The <orchestra> lists the names of the instruments that will be used in the <score>.  Each <token> in the <token list> corresponds to the name of an instrument.  The first instrument listed refers to the first instrument (instr 1) in a Music 11 orchestra, the second to instr 2, and so on.  The <orchestra> functions as a declarations section for instrument names.  If an instrument name in the <body> has not been listed in the <orchestra>, an error message will report this fact.  It is important to realize that the <orchestra> does not produce a Music 11 orchestra, but serves only to define the correspondence between Scot’s symbolic instrument names and the instrument numbers of a Music 11 orchestra.

Body

Syntax:

<body> ::=	<function section> <score section> |
	<body> <function section> <score section> |
	<body> <score section>

Semantics:

The <body> consists of <function section>s and <score section>s.  Each <score section> corresponds to a set of instrument statements in a Music 11 score section.  The <function section> immediately preceding a <score section> defines functions relative to the starting time of the following <score section>.  The first <score section> must be preceded by a <function section>, but succeeding <score section>s do not have this restriction.

Function section

Syntax:

<function section> ::=	functions { <any string of ASCII
	characters not containing a “}”> }

Semantics:

Music 11 function statements are written into the score by being specified in a <function section>.  Any characters following the open brace and preceding the close brace are copied character for character into the Music 11 score.  New line characters are inserted before and after this string to ensure that the first and last lines in the <function section> occupy only one line in the Music 11 score.  Scot does not do any syntactic checking before copying the character string into the Music 11 score.  Thus, any Music 11 score statement may be written at the beginning of a Music 11 score section by including it in the Scot <function section>.  This can be useful for instruments that perform continuously throughout a score section (e.g., a reverberation instrument).

Score section

Syntax:

<score section>	::=	score { <instrument part list> }
<instrument part list>	::=	<instrument part> |
		<instrument part list> <instrument part>
<instrument part>	::=	<instrument name> <event list>

Semantics:

The <score section>s are the main components of a <Scot score>.  Each <score section> contains one or more <instrument part>s.  An <instrument part> starts with an <instrument name> and is followed by the part for that particular instrument.  The part is written in the syntax of the <event list>, discussed below.  If a given instrument is specified in more than one <instrument part>, multiple copies of that instrument will be allocated by Music 11.

Event list: control events and note events

Syntax:

<event list>	::=	<event> |
		<event list> <event>
<event>	::=	<control event> |
		<compound note event>
<control event>	::=	<bar line> |
		<tempo mark> |
		<global>
<compound note event>	::=	<simple note event> |
		<simple note event> <
		<simple note event>

Semantics:

An <event list> may contain two types of events.

A note event contains information used to generate a series of one or more Music 11 note statements.  A <compound note event> is used to notate parts that are divisi in a given instrument.  Each <simple note event> corresponds to one or more notes in each specific divisi line.  Every <simple note event> contained within a <compound note event> starts at the same time.  For each <simple note event> following the first, unspecified durations are carried over from the preceding <simple note event>.  The first note event in an <event list> starts at time 0 relative to the start of the <score section>.

A <control event> modifies certain global information that is used in generating Music 11 notes.  The semantics of each type of <control event> will be discussed separately.

Simple note events and groups

Syntax:

<simple note event>	::=	<note> |
		<group>
<group>	::=	{ <note list> }
<note list>	::=	<note> |
		<note list> <note>

Semantics:

The <simple note event> construction is used to specify separate divisi lines on either a note by note basis or on a larger level.  Two or more <simple note event>s separated by backup signs (“<“) all start at the same time.  Octave placement is computed separately for each <simple note event> within a <compound note event>.  That is, the nth <simple note event> in a <compound note event> uses the scale degree of the nth <simple note event> in the preceding <compound note event> as a reference point for register computation.  Durations carry over in the same way.

Example:

The first two measures of Chopin’s Prelude, Op. 28, No. 6. can easily be represented by two instruments by the use of backups and groups as shown by the following <score section>:

Figure 1: Chopin excerpt

score {		; Figure 1–Chopin excerpt
	$right	; right hand
	!k “#fc”	; key signature
	!ti “3/4”	; time signature
	=d4 < f4 < (=b8 b)
	f4 < r4 < (b8 b)
	f < r < (b b) /	; end of measure
	d < f < (b b)
	d < f < (b b)
	d < f < (b b) /
	$left	; left hand
	$k “#fc”	; must specify again, just
	!ti “3/4”	; like traditional notation
	=,,b16 d f b d4 c8. d16 /	; notice octave following
	b4. f8 d c /
}

Note structure

Syntax:

<note>	::=	<note term> |
		<note term> <slur> |
		<note term> <tie> |
		<rest>
<rest>	::=	r |
		r <duration>
<note term>	::=	<note factor> |
		<note factor> <bracketed list>
<note factor>	::=	<compound pitch part> |
		<compound pitch part> <duration>
<compound pitch part>	::=	<simple pitch part> |
		<simple pitch part>
		<accidental list>
<simple pitch part>	::=	<pitch> |
		<octave marker> <pitch>
<pitch>	::=	a | b | c | d | e | f | g |
		A | B | C | D | E | F | G
<bracketed list>	::=	[ <any string of ASCII characters
		not containing “]”> ]
<duration>	::=	<integer> |
		<integer> <dot list>
<dot list>	::=	. |
		<dot list> .
<accidental list>	::=	<flat list> |
		<sharp list> |
		n
<flat list>	::=	– |
		<flat list> –
<sharp list>	::=	# |
		<sharp list> #
<octave marker>	::=	<comma list> |
		<apostrophe list> |
		= |
		= <comma list> |
		= <apostrophe list>
<comma list>	::=	, |
		<comma list> ,
<apostrophe list>	::=	‘ |
		<apostrophe list> ‘

Semantics:

In this case, Backus-Naur Form is a clumsy, though precise, way of specifying the syntax of a note.  A completely specified note, excluding a rest, has the following syntactic items in the following order:

<octave marker> <pitch> <accidental list>

<duration> <bracketed list> {<slur> | <tie>}

The one element that every <note> must have is a <pitch>, or an “r” indicating a rest.  Every other part of a note is optional.  If any part is not present, its value is carried over from the preceding <note> in the <instrument part>.  If this is the first <note> in the <instrument part>, default values are assumed.

An <octave marker> specifies the register of a note.  The equals sign refers to the octave starting at middle C and going up to B.  A comma lowers the register by one octave; an apostrophe raises the register by one octave.  Thus, “=,,c” would refer to the C two octaves below middle C.  If this note was then followed by “‘c”, this second note would be one octave below middle C.  If no equals sign is provided at the beginning of an instrument part, register placement is done as if a middle C preceded the first note.

There are two possibilities for choice of octave when a note has no octave marker.  The default is that the octave is adjusted so that the skip between the previous note and the current note is less than a fourth.  This interval is computed by scale degree, not by actual pitch (otherwise the tritone interval would be ambiguous).  A skip from C double flat to F double sharp goes up, not down.  If an <octave marker> without an equals sign is used, the octave following is computed first.  The resulting octave is then raised or lowered as specified by the <octave marker>.

The other possibility for register choice is to stay in the same absolute octave unless otherwise specified by an <octave marker>.  These octaves begin at C and end at the B a seventh higher.  This option is turned on and off by using the accidentals <switch>, whose use is discussed in the <control event> section.

A <pitch> is one of the seven degrees of the scale, taking on values from “a” to “g” (or, equivalently, “A” to “G”).  Pitch information is output in p5 using octave point pitch class (PCH) notation.  The <pitch> is the one item that must be specified for each <note> that is not a <rest>.

The <accidental list> modified the pitch of a note in the same way that accidentals do in traditional notation.  An <accidental list> can contain a natural sign “n”, a list of one or more sharps “#”, or a list of one or more flats “-“.  Each sharp raises the pitch a semitone from its natural value; each flat lowers the pitch a semitone from its natural value.  Flats, sharps, and naturals may not be combined in one <accidental list>.

By default, accidentals carry throughout the bar to all notes of the same pitch in any octave.  This agrees with 19th century notation, but not with the majority of 20th century notation.  Accidentals do not carry beyond a <bar line>, except when a note is tied across the bar line.

Accidental carrying can be turned on and off with the accidentals <switch>, just as octave following can be turned on and off with the octaves <switch>.  When turned off, accidentals apply only to the particular note modified, except when notes are tied.

A <duration> is a mnemonic value for the length of a note, with the following correspondences: whole note = 1; half note = 2; quarter note = 4; eighth note = 8; sixteenth note = 16; thirty-second note = 32; etc.  A dotted eighth note = 8.; a double dotted sixteenth = 16..; etc.  One note in a quarter note triplet has a <duration> of 6; a note in an eight note triplet has a <duration of 12.  To convert from <duration> to the actual length of the note in quarter note beats, divide 4 by the <duration>.  If the <duration> includes a dot, multiply the <duration> by two, divide 4, by this new value, and add to the total number of beats.  Repeat this procedure for each additional dot, multiplying the new duration value (not the original one) by two to start.  If no duration is specified at the beginning of an <instrument part>, a value of 4 (quarter note) is assumed.

Music 11 allows a note statement to use up to 50 parameter fields.  Scot reserves the first five of these, leaving the remainder available to the user by use of the <bracketed list>.  Parameter values, starting at p6, are listed within brackets and separated by commas.  Consecutive commas indicate that the p-field value is not set, in which case the value of the preceding note is carried over.  The values of p6 to p50 are all set to zero at the beginning of an <instrument part>.

To indicate a slur to the next <note>, include a <slur> in the current <note>.  A <slur> is represented by one underscore.  Slurring information is represented in p4 on the score card output for each <note>, as explained in [Gold 1978]: “Normally, p4 transmits slurring information: it equals 0 if the note is not slurred, 1 if is slurred to the next note only, 2 if is slurred only to the preceding note, and 3 if is slurred to both.”  This is a convention in Music 11, but it is enforced by Scot.  This enforcement may be removed in the near future, as discussed in the Extensions section.

Tied notes are indicated by a <tie> at the end of each <note> that is to be tied to the succeeding <note>.  A <tie> is represented by two underscores.  Only <note>s of identical pitch may be tied together.  The duration of the tied <note>s are added together, and one Music 11 instrument statement is output for the <note>s tied together.  The duration of the last <note>, not the entire duration of the tie, is the value carried to the next <note>.

Examples:

The first phrase of a certain popular tune

Figure 2: Twinkle, twinkle

may be represented with the following <score section>:

score {		; Figure 2–Twinkle, twinkle
	$twink	; instrument name
	=, b-8 b ‘f f g g f4	; accidental carries
		; and octave following done
}

If we want to syncopate the melody,

Figure 3: Syncopated twinkle, twinkle

we can change to this <score section>, if p6 controls amplitude:

score {		; Figure 3
	$twink
	=,b-8 [10000]	; p6 = amplitude
	b [12000]_’f[1000]	; add slurs
	f [12500]_g[10000]	; a little more
	g [12000]_f4[10000]
}

If we want to augment this motive, we might add ties

Figure 4: Twinkle, twinkle with ties

and use this <score section>:

score {		; Figure 4, example 1
	$twink
	=,b-8__b ‘f__f g__g f4	; ties added
}

We could also turn the accidental carry feature off and still have the same result, since the two B flats are tied:

score {		; Figure 4, example 2
	$twink
	!acc “off”	; turn off accidental carrying
	=,b-8__b ‘f__f g__g f4	; same as above
}

Note that both of these <score section>s produced the same Music 11 output that would be produced for the following phrase:

Figure 5: Augmentation of twinkle, twinkle

Bar line

Syntax:

<bar line> ::= /

Semantics:

When a <bar line> is reached, any accidentals that have been carried throughout the bar are cleared, with the exception of a note tied across the <bar line>.  If a time signature is being used, all copies of the instrument are checked to ensure that their last notes end at the proper time.  Divisi lines that continue to the last <note event> must include any trailing rests by using the <group> construction.  For example, in 4/4 time, “/c1<e2/” is incorrect, because the second copy of the instrument has too few beats in the bar.  This must be specified as “/c1<(e2 r2)/” to be correct.  This restriction applies only to the last <compound note event> in a bar.  A construction like “/c2<34 c2<e2/” is valid, even though the quarter rest for the second beat of the second copy was not specified.  Specifying the rests is advisable, though, to minimize the likelihood of errors.

Tempo mark

Syntax:

<tempo mark> ::= t <integer>

Semantics:

Globals

Syntax:

<global> ::=	<key signature> |
	<transposition> |
	<time signature> |
	<switch>

Semantics:

A <global> is an event that changes some global data that stays the same throughout an <instrument part> until a new <global> of the same type is encountered.  Each <global> will be discussed separately.

Key signature

Syntax:

<key signature>	::=	! <key> |
		! <key> “<key part list>”
<key part list>	::=	<key part> |
		<key part list> <key part>
<key part>	::=	<accidental list> <pitch> |
		<key part> <pitch>

Semantics:

<Key signature>s are specified by naming the accidental to be used and then listing the pitches affected by this accidental, repeating this process as many times as desired.  If a given <pitch> appears in more than one <key part>, the last of these <key part>s will be the one used for that <pitch>.  If the quoted <key part list> is absent, the key of all naturals is invoked.  It is not necessary to natural out the accidentals of a previous <key signature>; Scot does this automatically.

The exclamation point is referred to as the global mark.  It indicates that the next token is to be interpreted as a global keyword.  For the syntax of these keywords, refer to the Basic Symbols section above.

Examples:

If we rewrite our popular tune using a key signature,

Figure 6: Twinkle, twinkle with a key signature

we could rewrite the <score section> as follows:

score {		; Figure 6
	$twink
	!acc “on”	; turn on accidental carrying
	!k “-be”	; B flat major
	=,b8 b ‘f f g g f4	; no accidentals
}

Because the user specifies the accidentals and the pitches, unusual <key signature>s pose no problems, as this example from the first two measures of Béla Bartók’s Mikrokosmos, Vol. IV, no. 99 (“Crossed Hands”) shows:

Figure 7: Bartók excerpt.

score {		; Figure 7–Bartok excerpt
	$right	; right hand
	!k “-e”	; e flat only
	!ti “3/4”	; time signature
	t 72	; M.M. quarter note = 72
	=c8 d e4. f8/	; don’t need initial =
	e8 d c4. b8/
	$left	; left hand
	!k “#fg”	; different key signature
	!ti “3/4”	; same time signature
	=’c4. b8 c b/
	c4. b8 a b/
}

Transposition

Syntax:

<transposition> ::=	! <transpose> |
	! <transpose> “<compound pitch part>”

Semantics:

A <transposition> indicates how much the pitches in the following <compound note event>s are offset from concert pitch.  The difference between the pitch indicated by the <compound pitch part> and middle C is the amount of the offset.  If the quoted <compound pitch part> is absent, the notes are assumed to be written at concert pitch.

Example:

If we were writing “Twinkle, twinkle” for a B flat clarinet,

Figure 8: Twinkle, twinkle for clarinet.

we might rewrite the <score section> to reflect the transposing nature of the instrument:

score {		; Figure 8
	$clarinet	; instrument
	!tr “,b-“	; B flat below middle C
	=c8c ‘gg aa g4	; spacing is irrelevant
}

Time signature

Syntax:

<time signature> ::=	! <time> |
	! <time> ” <integer> / <integer> “

Semantics:

The use of a <time signature> is purely an error detection mechanism.  When a time signature is specified, all the instrument copies will be checked at the conclusion of each bar to ensure that the proper number of beats has elapsed since the bar started.  When the <time signature> is not present, this checking is not done.  The <time signature> is specified (in quotes) in the traditional way, with the very minor esception that both numbers must be <integer>s.

Examples:

<Time signature>s are used in the excerpts from Chopin, Bartók, and Babbitt.

Switches

Syntax:

<switch> ::=	! <accidentals> “on” |
	! <accidentals> “off” |
	! <octaves> “on” |
	! <octaves> “off”

Semantics:

The accidental carrying and octave following <switch>s have been discussed in the section on the <note>.  When “on” is the last item, the particular feature is turned on; when “off” is the last item, the particular feature is turned off.  Both <switch>s have a default value of “on”.  Unlike other <global>s, <switch>s are not reset at each new <instrument part> or <score section>; they retain their value until they are explicitly changed.

Example:

In writing complex scores, it is likely that using the accidental carrying and octave following features will hinder the user.  When the composer specified, “Accidentals affect only those notes which they immediately precede, except when notes are tied,” the accidentals <switch> should certainly be turned off [Babbitt 1957].  In the first two measures of Milton Babbitt’s Three Compositions for Piano, turning off the octave <switch> also is helpful, as the following <score section> shows:

Figure 9: Babbitt excerpt.

score {		; Figure 9–Babbitt excerpt
	$left	; left hand
	t 108	; M.M. quarter note = 108
	!acc “off”	; turn off carrying of accidentals
		; per composer’s instructions
	!oct “off”	; turn off octave following
		; for convenience
	!time “3/4”	; time signature
	=,,b-16 c- f d c4__ c16 d- r8 /
	g16 b f# a__a4 a-16 e16__e8
	$right	; right hand
	!time “3/4”
	r4 =,e16 a ,b ‘a- ‘f#8 ,g16 r /
	r4 ‘d-16 ,f ‘c ,e-__e8 ‘d16 b-32 r /
}

Scot and SOGO

SOGO was designed as a language for introducing MIT students to the Experimental Music Studio during a seminar offered during the January 1978 Independent Activities Period.  Its syntax was modeled on ALMA with extensions to allow for synthesis within the Music 11 system.  SOGO requires only one file to synthesize a composition, as it generates both the Music 11 score and orchestra.  The orchestra is generated using the orchestra archiver, a program that is not part of the general Music 11 system.  While requiring only one file is helpful for beginning users who have not been exposed to Music 11 previously, composers who were recently introduced to Music 11 and then exposed to SOGO had some difficulties in understanding the differences between the two systems.

Scot, on the other hand, is exclusively a score translator that produces a Music 11 score as its entire output.  It is more closely integrated into the general Music 11 system than is SOGO, as it does not depend on a program external to the system.  Scot also gives the composer more flexibility in using already existing orchestras than SOGO does, since the only information that a composer gives about the orchestra is the attaching of symbolic names to the already existing instruments.  SOGO required composers to either rewrite their instrument definitions into the SOGO file or limit themselves to orchestras that were compatible with the orchestra archiver program.

There are some features present in Scot that are not present in SOGO.  Time signatures, transpositions, and switches are all new additions to the language.  Ties and slurs are now syntactically distinct items.  The syntax of the key signature was changed to correspond more closely to these new features.

An existing feature of SOGO, the backup facility, has been improved.  Slurs and backups are now handled correctly, and separate octave following and duration carrying is now available for the different voices in a divisi passage.  For one instrument to play a C major scale in parallel octaves with one voice in quarter notes and the other in offbeat eighth notes, SOGO required “c4<‘r8c, d4<‘r8d, e4<‘r8e”, etc.  All the notes were considered to be part of one voice in the computation of octave following and in the carrying of durations. In Scot, all that is needed is “c4<‘r8c d<rd e<re”, etc.

The implementation of the two languages differs drastically.  SOGO was implemented using a parser written in C [Kernighan and Ritchie 1978].  This parser was built in the week preceding the January seminar, and does not appear to be particularly adaptable.

Scot is implemented as a YACC specification file.  YACC (Yet Another Compiler-Compiler) is given a set of grammar rules, translation procedures for these grammar rules, and a lexical analyzer; it then generates a compiler for this LALR (1) grammar [Johnson 1975; Aho and Ullman 1977].  The compiler so produced is written in C, as are all the procedures given in the YACC specifications.   The syntax presented in the preceding chapter is condensed from the grammar rules given to YACC.

The specification of grammar rules makes changes in syntax much easier to implement, and assists greatly in the preparation of program documentation (an area in which SOGO is sadly lacking).  The ability to make changes in syntax rapidly and accurately has been well exploited during Scot’s development.  For example, the entire mechanism for the handling of globals, including the handling of time signatures, was developed in one day.  The speed with which this rather substantial change was implemented indicates that the features propose din the next section may be implemented in the very near future.

Suggested Extensions

There are three main deficiencies in the current implementation of Scot.  One of these is the absence of any symbolic way to specify dynamics or articulations other than slurs.  This is related to the problem of Scot’s rigid adherence to the Music 11 conventions about the use of p4 and p5.  Another is the lack of structures to facilitate repetition.  The third is the absence of a lookahead facility enabling one <note> to produce a Music 11 statement that includes information about the next <note>.  All of these deficiencies may be overcome in the future by extending existing syntactic items to cover these areas.

The problems of specifying dynamics and choosing the information to be contained in various p-fields can be approached by extending the <global> construction.  The standard dynamics could each have an associated <global> that would assign that dynamic value to the following notes until either a different dynamics <global> was encountered or the <instrument part> ended.  Optionally, each dynamic level could be assigned a numeric value at the same time–Scot would provide default values.  For those composers who do not like the conventional dynamic markings, an additional <global> “dynamics” would be available to avoid the connotations of “ff”, “mp”, etc.

In a similar way, the composer could use <global>s to specify which symbolic information is to be contained in a certain p-field.  There would be <global>s to assign a particular parameter to p4, p5, or p6.  This corresponds to the three types of symbolic data that could be passed in this manner.  The bracketed list would then start assigning p-fields at the lowest p-field left unspecified.  This feature could also be used to make p-field assignments outside of the <bracketed list>.

Examples of these new <global>s would include:

!p4 “pitch”	; Pitch is contained in p4
!p5 “dynamics”	; and dynamics in p5.
	; No assignment to p6, so
	; bracketed list will start
	; assigning values there.
!p7 “100”	; assign p7 the value 100
!ff “20000”	; Specify fortissimo.
!dynamic “500”	; Assign a general dynamic.
	; All other dynamics–f, mf,
	; mp, p, and pp–assume
	; default values.

The ability to specify crescendo or diminuendo is related primarily to another problem and will be discussed below.

It is possible that a similar arrangement could be worked out for specifying various articulations such as staccato, legato, marcato, etc., but the problems here tend to be much more instrument-dependent than the assignment of dynamic indications.  To change the articulation, the attack shape must be changed; but there are many different ways for an instrument to define an attack shape.  Thus the symbolic specification of articulations is to a large part a Music 11 problem.  If the handling of articulations among Music 11 instruments was as standardized as their handling of dynamics, this problem would not exist.

The second major problem in Scot is the lack of a larger scale structure that would allow both for repeats and for changing of variables at a certain specified rate over a period of time (as is done by the tempo routine in the Music 11 system).  This problem can be addressed by expanding the notion of <group>s.  Substituting <event list> for <note list> in the rule concerning <group>s would provide a recursive syntax, but would not affect the grammar’s LALR (1) status.  <Group>s could then be implemented by linked lists in the same way that <compound note event>s are currently implemented.  <Group>s would have much greater semantic power, but the nature of their semantics must be thought out further before implementation can proceed.

One use of <group>s would allow the specification of an arbitrary number of repeats over a series of notes of any size.  Another use would be the ability to specify changes in arbitrary parameter values over the duration of the <group>.  Changing the parameter regarding dynamics would produce a crescendo or a diminuendo; changing other instrument-specific parameters might provide for steady changes in timbre.  The changes could be linear (like tempo), exponential, or specified by an arbitrary function table, using techniques borrowed from other parts of the Music 11 system.  In the near future, only the linear change appears as a likely candidate for implementation since the other possibilities would require a substantially greater amount of computation.

With p-field specifications and <group>s implemented, lookaheads become easy to process.  One p-field can be specified as the next value of another p-field: for example, ” !p7 “next p5″ ” would assign p7 the next value of p5.  After this definition, p7 could not be assigned by the <bracketed list> construct.  The <bracketed list> [1,1] would assign values to p6 and p8, leaving p7 alone (assuming that the list starts at p6).  A full implementation of <group>s is not necessary for lookahead.  A mechanism for handling two <compound note event>s is needed, however, and this would probably be a degenerate case of the <group> implementation.

One of the most useful features of the current Scot implementation is the ease with which it allows many of these types of changes to be made.  When they are implemented in the not-too-distant future, Scot will have evolved one more step away from the musicological concerns of ALMA and the pedagogic concerns of SOGO to take its place as a powerful compositional tool in the Music 11 system.

References

Aho, Alfred V., and Ullman, Jeffrey D. 1977.  Principles of Compiler Design.  Reading, Mass.: Addison-Wesley.

Babbitt, Milton 1957.  Three Compositions for Piano.  Hillsdale, N.Y.: Boelke-Bomart.

Bauer-Mengelberg, Stefan 1970.  “The Ford-Columbia Input Lanaguage.”  In Musicology and the Computer, ed. Barry S. Brook.  New York: City University of New York Press, pp. 48-52.

Brook, Barry S. 1970a.  “The Plaine and Easie Code.”  In Musicology and the Computer, ed. Barry S. Brook.  New York: City University of New York Press, pp. 53-56.

Brook, Barry S., Ed. 1970b.  Musicology and the Computer.  Greater New York Chapter of the American Musicological Society proceedings.  New York: City University of New York Press.

Brown, Frank 1977.  “The Language Scriptu.”  Interface, 6, 9-28.

Erickson, Raymond 1977.  “Musicomp 76 and the State of DARMS.”  College Music Symposium, 17:1, 90-101.

Gold, Michael 1978.  “A Quick Introduction to Music 11.”  Unpublished typescript, Experimental Music Studio, MIT, June 25.

Gould, Murray J., and Logemann, George W. 1970.  “ALMA: Alphameric Language for Music Analysis.”  In Musicology and the Computer, ed. Barry S. Brook.  New York: City University of New York Press, pp. 57-90.

Hiller, Lejaren A., and Baker, Robert A. 1965.  “Computer Cantata: A Study in Compositional Method.”  Perspectives of New Music, 3:1, 62-90.

Hiller, Lejaren A., and Isaacson, Leonard M. 1959.  Experimental Music.  New York: McGraw-Hill.

Howe, Carl D. 1978.  “The SOGO Language.”  Unpublished typescript, Experimental Music Studio, MIT, June 11.

Johnson, Stephen C. 1975.  “YACC–Yet Another Compiler-Compiler.”  Bell Laboratories, Murray Hill, N.J.

Kernighan, Brian W., and Ritchie, Dennis M. 1978.  The C Programming Language.  Englewood Cliffs, N.J.: Prentice-Hall.

MacInnis, Donald 1968.  “Sound Synthesis by Computer: MUSIGOL, a Program Written Entirely in Extended ALGOL.”  Perspectives of New Music, 7:1, 66-79.

Mathews, Max V. 1961.  “An Acoustic Compiler for Music and Psychological Stimuli.”  Bell Telephone Technical Journal, 40, 677-94.

——- 1969.  The Technology of Computer Music.  Cambridge, Mass.: The M.I.T. Press.

Naur, Peter, ed. 1963.  “Revised Report on the Algorithmic Language ALGOL 60.”  Communications of the ACM, 6, 1-17.

Rogers, John E. 1975.  “The Uses of Digital Computers in Electronic Music Generation.”  In The Development and Practice of Electronic Music, ed. Jon H. Appleton and Ronald C. Perara.  Englewood Cliffs, N.J.: Prentice-Hall, pp. 189-285.

Smith, Leland 1972.  “SCORE–A Musician’s Approach to Computer Music.”  Journal of the Audio Engineering Society, 20, 7-14.

Vercoe, Barry 1973.  “Reference Manual for the MUSIC 360 language for digital sound synthesis.” Unpublished typescript, Studio for Experimental Music, MIT.

——– 1978.  “Reference Manual for the MUSIC 11 Sound Synthesis Language.”  Unpublished typescript, Experimental Music Studio, MIT.

Appendix: Scot Output for Figures

The Scot examples accompanying the figures were moved into the complete Scot file given below, where each score section represents one example:

orchestra {		; list of all instruments
	right left twink clarinet
}
functions {
	f1 0 256 10 1	; sine wave
}
score {		; Figure 1–Chopin excerpt
	$right	; right hand
	!k “#fc”	; key signature
	!ti “3/4”	; time signature
	=d4 < f4 < (=b8 b)
	f4 < r4 < (b8 b)
	f < r < (b b) /	; end of measure
	d < f < (b b)
	d < f < (b b)
	d < f < (b b) /
	$left	; left hand
	$k “#fc”	; must specify again, just
	!ti “3/4”	; like traditional notation
	=,,b16 d f b d4 c8. d16 /	; notice octave following
	b4. f8 d c /
}
score {		; Figure 2–Twinkle, twinkle
	$twink	; instrument name
	=, b-8 b ‘f f g g f4	; accidental carries
		; and octave following done
}
score {		; Figure 3
	$twink
	=,b-8 [10000]	; p6 = amplitude
	b [12000]_’f[10000]	; add slurs
	f [12500]_g[10000]	; a little more
	g [12000]_f4[10000]
}
score {		; Figure 4, example 1
	$twink
	=,b-8__b ‘f__f g__g f4	; ties added
}
score {		; Figure 4, example 2
	$twink
	!acc “off”	; turn off accidental carrying
	=,b-8__b ‘f__f g__g f4	; same as above
}
score {		; Figure 6
	$twink
	!acc “on”	; turn on accidental carrying
	!k “-be”	; B flat major
	=,b8 b ‘f f g g f4	; no accidentals
}
score {		; Figure 7–Bartok excerpt
	$right	; right hand
	!k “-e”	; e flat only
	!ti “3/4”	; time signature
	t 72	; M.M. quarter note = 72
	=c8 d e4. f8/	; don’t need initial =
	e8 d c4. b8/
	$left	; left hand
	!k “#fg”	; different key signature
	!ti “3/4”	; same time signature
	=’c4. b8 c b/
	c4. b8 a b/
}
score {		; Figure 8
	$clarinet	; instrument
	!tr “,b-“	; B flat below middle C
	=c8c ‘gg aa g4	; spacing is irrelevant
}
score {		; Figure 9–Babbitt excerpt
	$left	; left hand
	t 108	; M.M. quarter note = 108
	!acc “off”	; turn off carrying of accidentals
		; per composer’s instructions
	!oct “off”	; turn off octave following
		; for convenience
	!time “3/4”	; time signature
	=,,b-16 c- f d c4__ c16 d- r8 /
	g16 b f# a__a4 a-16 e16__e8
	$right	; right hand
	!time “3/4”
	r4 =,e16 a ,b ‘a- ‘f#8 ,g16 r /
	r4 ‘d-16 ,f ‘c ,e-__e8 ‘d16 b-32 r /
}
end

The Music 11 score output by Scot follows below:

	f1 0 256 10 1
i1.1	0.0000	1.0000	0	8.02
i1.2	0.0000	1.0000	0	8.06
i1.3	0.0000	0.5000	0	8.11
i1.3	0.5000	0.5000	0	8.11
i1.1	1.0000	1.0000	0	8.06
i1.3	1.0000	0.5000	0	8.11
i1.3	1.5000	0.5000	0	8.11
i1.1	2.0000	1.0000	0	8.06
i1.3	2.0000	0.5000	0	8.11
i1.3	2.5000	0.5000	0	8.11
i1.1	3.0000	1.0000	0	8.02
i1.2	3.0000	1.0000	0	8.06
i1.3	3.0000	0.5000	0	8.11
i1.3	3.5000	0.5000	0	8.11
i1.1	4.0000	1.0000	0	8.02
i1.2	4.0000	1.0000	0	8.06
i1.3	4.0000	0.5000	0	8.11
i1.3	4.5000	0.5000	0	8.11
i1.1	5.0000	1.0000	0	8.02
i1.2	5.0000	1.0000	0	8.06
i1.3	5.0000	0.5000	0	8.11
i1.3	5.5000	0.5000	0	8.11
i2.1	0.0000	0.2500	0	6.11
i2.1	0.2500	0.2500	0	7.02
i2.1	0.5000	0.2500	0	7.06
i2.1	0.7500	0.2500	0	7.11
i2.1	1.0000	1.0000	0	8.02
i2.1	2.0000	0.7500	0	8.01
i2.1	2.7500	0.2500	0	8.02
i2.1	3.0000	1.5000	0	7.11
i2.1	4.5000	0.5000	0	7.06
i2.1	5.0000	0.5000	0	7.01
i2.1	5.5000	0.5000	0	7.01
t0 60
s
i3.1	0.0000	0.5000	0	7.10
i3.1	0.5000	0.5000	0	7.10
i3.1	1.0000	0.5000	0	8.05
i3.1	1.5000	0.5000	0	8.05
i3.1	2.0000	0.5000	0	8.07
i3.1	2.5000	0.5000	0	8.07
i3.1	3.0000	1.0000	0	8.05
t0 60
s
i3.1	0.0000	0.5000	0	7.10	10000
i3.1	0.5000	0.5000	1	7.10	12000
i3.1	1.0000	0.5000	2	8.05	10000
i3.1	1.5000	0.5000	1	8.05	12500
i3.1	2.0000	0.5000	2	8.07	10000
i3.1	2.5000	0.5000	1	8.07	12000
i3.1	3.0000	1.0000	2	8.05	10000
t0 60
s
i3.1	0.0000	1.0000	0	7.10
i3.1	1.0000	1.0000	0	8.05
i3.1	2.0000	1.0000	0	8.07
i3.1	3.0000	1.0000	0	8.05
t0 60
s
i3.1	0.0000	1.0000	0	7.10
i3.1	1.0000	1.0000	0	8.05
i3.1	2.0000	1.0000	0	8.07
i3.1	3.0000	1.0000	0	8.05
t0 60
s
i3.1	0.0000	0.5000	0	7.10
i3.1	0.5000	0.5000	0	7.10
i3.1	1.0000	0.5000	0	8.05
i3.1	1.5000	0.5000	0	8.05
i3.1	2.0000	0.5000	0	8.07
i3.1	2.5000	0.5000	0	8.07
i3.1	3.0000	1.0000	0	8.05
t0 60
s
i1.1	0.0000	0.5000	0	8.00
i1.1	0.5000	0.5000	0	8.02
i1.1	1.0000	1.5000	0	8.03
i1.1	2.5000	0.5000	0	8.05
i1.1	3.0000	0.5000	0	8.03
i1.1	3.5000	0.5000	0	8.02
i1.1	4.0000	1.5000	0	8.00
i1.1	5.5000	0.5000	0	7.11
i2.1	0.0000	1.5000	0	9.00
i2.1	1.5000	0.5000	0	8.11
i2.1	2.0000	0.5000	0	9.00
i2.1	2.5000	0.5000	0	8.11
i2.1	3.0000	1.5000	0	9.00
i2.1	4.5000	0.5000	0	8.11
i2.1	5.0000	0.5000	0	8.09
i2.1	5.5000	0.5000	0	8.11
t0 60	0.0000	72.0000
s
i4.1	0.0000	0.5000	0	7.10
i4.1	0.5000	0.5000	0	7.10
i4.1	1.0000	0.5000	0	8.05
i4.1	1.5000	0.5000	0	8.05
i4.1	2.0000	0.5000	0	8.07
i4.1	2.5000	0.5000	0	8.07
i4.1	3.0000	1.0000	0	8.05
t0 60
s
i2.1	0.0000	0.2500	0	6.10
i2.1	0.2500	0.2500	0	6.03
i2.1	0.5000	0.2500	0	6.05
i2.1	0.7500	0.2500	0	6.02
i2.1	1.0000	1.2500	0	6.00
i2.1	2.2500	0.2500	0	6.01
i2.1	3.0000	0.2500	0	6.07
i2.1	3.2500	0.2500	0	6.11
i2.1	3.5000	0.2500	0	6.06
i2.1	3.7500	1.2500	0	6.09
i2.1	5.0000	0.2500	0	6.08
i2.1	5.2500	0.7500	0	6.04
i1.1	1.0000	0.2500	0	7.04
i1.1	1.2500	0.2500	0	7.09
i1.1	1.5000	0.2500	0	6.11
i1.1	1.7500	0.2500	0	7.08
i1.1	2.0000	0.5000	0	8.06
i1.1	2.5000	0.2500	0	7.07
i1.1	4.0000	0.2500	0	8.01
i1.1	4.2500	0.2500	0	7.05
i1.1	4.5000	0.2500	0	8.00
i1.1	4.7500	0.7500	0	7.03
i1.1	5.5000	0.2500	0	8.02
i1.1	5.7500	0.1250	0	8.10
t0 60	0.0000	108.0000
s
e