Perspectives of New Music Perspectives of New Music

TEMPO: A Composer's Programming Language
Author(s): John Clough

Source: Perspectives of New Music, Vol. 9, No. 1 (Autumn - Winter, 1970), pp. 113-125
Published by: Perspectives of New Music
Stable URL: http://www.jstor.org/stable/832197
Accessed: 19-06-2017 20:09 UTC
JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range of content in a trusted
digital archive. We use information technology and tools to increase productivity and facilitate new forms of scholarship. For more information about
JSTOR, please contact support@jstor.org.
Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
http://about.jstor.org/terms
Perspectives of New Music is collaborating with JSTOR to digitize, preserve and extend access to
Perspectives of New Music
This content downloaded from 90.214.205.250 on Mon, 19 Jun 2017 20:09:50 UTC
All use subject to http://about.jstor.org/terms
FORUM: COMPUTER RESEARCH
TEMPO: A COMPOSER'S PROGRAMMING

LANGUAGE
JOHN CLOUGH
TEMPO (Transformational Electronic Music Process Organizer) is a

special-purpose programming language for the generation of sound
by means of digital computers. The author began work on the lan-
guage in the fall of 1968 and completed the preliminary specifications
in the summer of 1969 in collaboration with Eric Sosman, who is also
writing the TEMPO language processor. An initial implementation on
the IBM 360/model 44 is expected to be complete by September 1971.1
The development of TEMPO is part of an ongoing research project
at Oberlin College, sponsored since May 1969, by the National Sci-
ence Foundation. Two other major activities of the project, now in
progress but not specifically reported in the present article, are real-
time digital synthesis and exploration of undergraduate educational
uses of computer sound-generation.
In addition to Sosman and the author, contributors to the project
include Robert Teitel, who serves as consultant in the development of
TEMPO, and Judson Leonard, who wrote PLAY, a program which
controls the digital-to-analog conversion process, and MUTILS, a set
of routines for real-time synthesis.
Special purpose facilities for music at the Oberlin College Com-
puter Center include a 4-channel digital-to-analog conversion system,
on line to the 360/44. In addition to using the regular batch-proces-
sing services at the Computer Center, the project is able to reserve
blocks of off-hours time for the dedicated use of the computer as a
real-time music system.
The present article will survey the important features of TEMPO
without making any attempt at exhaustiveness. The intent is neither
to give a condensation of the language specifications,2 nor to teach the
reader how to program in the TEMPO language, but rather to intro-
1This implementation will be generally compatible throughout System 360. An

implementor's manual will accompany the exported version of TEMPO.
2 These are given in full detail in TEMPO: Preliminary Specifications, by J. Clough and
E. Sosman, available through the author.
* 113
PERSPECTIVES OF NEW MUSIC
duce concepts which played a part in its design and to

thing of its capabilities in relation to existing program
for music generation. Particular stress is laid upon the
automatic generation of the score, for these are at the
most novel and most powerful features of the langu
syntax are treated only insofar as their consideration s
poses outlined above.
Familiarity with the basic physical concepts of comp
generation is assumed on the part of the reader, wh
easier time following the exposition if he also has at lea
knowledge of an existing sound-generation program.3
Programs such as the Bell Telephone Laboratories'

erally have required two kinds of input for each job
program written in a macro-assembler or high level la
BEFAP or FORTRAN, and a score consisting of fixe
meric data. In the BTL Music V, the score and orchestr
parts of the same data collection, the format of which
language-like. TEMPO represents the next logical step
tion: a full-fledged special-purpose language.
A program in TEMPO, like a program in FORTRAN
language, consists of a sequence of statements. (In TEM
other languages, the end of each statement is marked b
However, TEMPO is unusual in that its sequence of sta
fies a sequence of events, with the complication that t
quences are, in general, different. This complication ar
obvious fact that in music, logical and chronological or
tinct. The manner in which TEMPO reflects this distinction must now
be examined.
There are three passes in the complete execution of a program in

TEMPO:
Pass 1: Compilation
Pass 2: Sorting
Pass 3: Performance
Pass 1 input is a program in TEMPO. Its output is the perfor

file, a collection of numeric data representing instruments, fun
notes, and other entities. Some statement types (the CONS
statement, for example) result in the immediate creation of ou
the performance file. Other statement types (the STRING stat
for example) can have an effect on the content of later output
3 An introduction to the technology and to one such program (Music V) is co
in M. V. Mathews The Technology of Computer Music, MIT Press, 1969.
114-
performance file, but do not themselves create such outpu

statement types (the PLAY statement, for example) may
create such output. Statements in the first category have
which specify their chronology in the music, or they are
blocks which have action times; most statements in the second cate-
gory do not have action times since they operate only in Pass 1. Thus,
there are two kinds of sequencing in TEMPO: the physical sequencing
of statements in a program, and the designated chronological se-
quencing of statements with action times. The distinction between the
two kinds of sequencing, and between statements with and without
action times is of central importance in TEMPO.
Since statements with action times need not be physically sequenced
in the order of their action times, sorting of the performance file is
necessary. This is done in Pass 2 along with certain other necessary
functions preparatory to Pass 3, in which the actual samples are com-
puted. Since, for the purposes of language specification, Pass 2 is not
distinct from Pass 3, it is convenient to speak of only two general
classes of program elements: compiler elements and performance
elements. These two classes of elements are listed below:
Compiler elements Performance elements

set instrument
transform box
word function
string note
compiler variable performance variable
Though compilation precedes performance in the processing of a

program in TEMPO, it is easier to describe the two classes of elements
in reverse order:
Instruments can be thought of as complex operators or subroutines.

They combine and process information from the other performance
elements to produce output samples. Instruments are built according
to the user's design from smaller operators called unit generators
Boxes are storage areas used for passing data between unit gen
erators. Usually they provide intra-instrument communication, but
inter-instrument communication is also possible. In most implemen-
tations of TEMPO, a box actually will be a block of locations (vector)
but it may be thought of as a single location (scalar) by the pro-
grammer.
Functions contain descriptions of waveforms, amplitude and pitch
modulations, envelopes, and other entities. The descriptions are
stored as sequential lists of numbers which are sampled in various
ways.
115
A note is a collection of numeric quantities describing

A note includes quantities specifying its action time (s
duration, the number of the instrument which is to pla
any parameters required by that instrument.
Performance variables are scalars used for various con
Like notes, they may supply information to instrume
the parameters of a note operate only during the playin
while the value of a defined performance variable rem
until the variable is redefined.
A set is a collection of more-or-less well formed note descriptions
that is held in memory during compilation. After a set is defined,
may be repeatedly used, in original form or in modified form, in th
creation of actual notes. The set block itself does not create output fo
the performance file; the appearance of the name of the set in
phrase-type PLAY statement does create output for the performanc
file.
A transform is analogous to a subroutine. After it is initially processed

during compilation, it is held in memory as an adjunct to the processor
itself. When notes are created by referencing a set, a transform can
modify and supplement the specifications obtained from the set.
Thus, sets and transforms are effectively data and programs which
may be activated repeatedly during compilation.
A word is a specified sequence of transforms. If such a sequence is to
be used more than once, it may be convenient to define a word whose
name may then be used as a kind of abbreviation.
A string is a collection of sets. Each set in the string may or may not
have transforms associated with it. Like a word name, a string name
is a kind of abbreviation. The use of strings instead of larger sets saves
storage space, which may or may not be a consideration at a particular
installation where TEMPO is implemented.
Compiler variables are single-valued numeric quantities defined dur-
ing compilation.
The distinction between compiler and performance elements is
well illustrated by the LET statement, which may or may not carry an
action time:
LET X= 12; (1)

AT 1 LET Y= 12; (2)
Statement (1) defines a comp

a performance variable. Stat
statement is encountered by t
Statement (2) says, in effect: "
formance, set the value of Y to
116
In general, any numeric quantity in TEMPO may be a

an expression containing one or more variables, as well
A TEMPO program consists of free statements and

blocks. Following is a list of free statements and their p
type of statementpurpose
PLAY play a note or a set of notes
CONSTRUCT define a function
LET define a variable
STRING define a set of notes in terms of other sets
WORD define a sequence of transforms
SECTION end a section
TERMINATE end a piece
DELETE
delete an instrument or function (to save storage
space)
A block is a series of statements initiated by a header statement and
concluded by an END statement. There are four types of statement
blocks, identified by type of header statement:
INSTRUMENT-block
CONSTRUCT-block
SET-block
TRANSFORM-block
An INSTRUMENT-block defines an instrument in terms of unit-

generator statements such as OSCIL and ENVELOPE, which refer to
the complex operators in the body of the instrument. Also available in
instrument definition are the following auxiliary statements: EVAL-
UATE, which evaluates an expression (expressions are also permitted
as inputs to unit generators); RESERVE, which permits inter-instru-
ment communication; the four statements IF, THEN, ELSE, and
ENDIF which test conditions and control branching.
A function requiring segment-by-segment definition is defined in a
CONSTRUCT-block. The LOAD, ADD, and MULTIPLY statements
permit a function segment to be defined directly or as the result of an
operation on an existing segment and a newly defined vector.
A SET-block contains a collection of PLAY statements defining a
set. A TRANSFORM-block may contain LET statements, which as-
sign values to variables, DO and DONE statements to control itera-
tion, and IF, THEN, ELSE, and ENDIF statements for conditional
branching. The interaction between these two types of blocks is illus-
trated later.
117
Since the pivotal entity in the execution of a program

the instrument, it is natural to begin with comments on
the language, despite its complexities. TEMPO instru
fined in a kind of sublanguage which attempts to com
gance of a macro-assembler language with the expre
capabilities of FORTRAN.
Following is a definition of a more or less trivial instr
INSTRUMENT TRIVIAL: PITCH = &P1 ACCENT = &P2; (1)

(PITCH) EVALUATE HZ (PITCH); (2)
OSCIL F(AUDIO), PITCH; (3)
LINENVLP .01, .01; (4)
OUTPUT (LOUDNESS + ACCENT)*&X *&Y (5)
END; (6)
In stateme
&P1 and &P
statements
indicates t
PITCH has
In statem
and OUTPU
in each stat
operation,
put symbols.
In statement (2) the parentheses around the rightmost "PITCH"
indicate that it is an argument to the conversion routine "HZ." State-
ment (2) says in effect: "Take the first note parameter, convert it
from Hz to an increment for sampling a stored function, and replace
the result in the first note parameter location."
The oscillator in statement (3) uses the increment computed in
statement (2) to sample a function called AUDIO which must be de-
fined elsewhere in the program. TEMPO oscillators are unary opera-
tors; there is no multiplier or amplitude input.4
Statement (4) calls for a linear rise and a linear decay of .01 seconds
duration each.
The OUTPUT statement simply evaluates the given expressio

and adds the result to an output buffer. LOUDNESS is a varia
which will be defined before notes for TRIVIAL are played. &X and
&Y refer to the outputs of the immediately previous statement an
the immediately previous statement but one, respectively.
4 In TEMPO, functions may be rescaled to any desired maximum absolute val
(when the maximum is not specified by the programmer, it defaults to 1). Theref
an internal multiplier would waste computation time whenever the amplitude in
remained constant during the course of a note.
118
Following is a block diagram of TRIVIAL:

HZ(PITCH)
V .01 .01 LOUDNESS ACCENT

F (AUDIO) LINENVLP < I
A lBI
I A * B * (LOUDNESS + ACCENT) I
I
The output of the oscil ator, labeled A, wil normally range be-
tween + 1 and -1, although this range may be specified as desired.
The output of the envelope control wil be + 1 during the steady state,
zero at the beginning and end of a note, with linear progression be-
tween these values during rise and decay. As a result, the output of
the instrument will have a maximum absolute value of LOUDNESS +
ACCENT.
An individual note is defined in a PLAY statement:
AT A + 14 PLAY TRIVIAL FOR 1.5: 440, 100;
The phrase "AT A + 14" directs that the note begin 14 beats af
A, a variable defined elsewhere. "PLAY" is the verb identifying
statement as a note definition.
"TRIVIAL," the instrument name, is in fact a variable whose value
would have been automatically assigned by the instrument definit
given above. The composer can control this assignment if he wish
and can redefine the instrument name (by means of a LET statemen
just as he would redefine any other variable. This reflects the phil
ophy that bookkeeping chores should be delegated to the system,
less the composer wishes to assume them for some special reason.
To continue with an explanation of the above PLAY statement, t
two numbers following the colon are the parameters for frequenc
and accent, as required by TRIVIAL. (They could be expressio
As a courtesy to the experienced programmer, keywords may be
abbreviated in all TEMPO statements. If the value of TRIVIAL is 1,
the above statement could be shortened to:
A A + 14 P 1 F 1.5: 440, 100;
However, the printed output of TEMPO displays the unabbreviated

form for greater readability, except in the case of syntax and other
errors, when the offending statement is also displayed exactly as
119
written by the programmer. For the sake of consistency, th

forms of keywords are used throughout the present articl
A function is defined by means of a CONSTRUCT state
AT 0 CONSTRUCT AUDIO USING SINES:
(1 TO 16 BY 3: 10, 1*5);
The above calls for the construction of a function named AUDIO
at time zero, by means of a routine called SINES. "1 TO 16 BY 3
calls for harmonics numbered 1, 4, 7, 10, 13, and 16. The relative
strength of the first member of this series (in this case the funda-
mental) is 10; the relative strengths of the remaining 5 members are
in all cases 1.
As in other sound-generation systems, functions need not be de-
fined in terms of trigonometric series; they may be defined, for ex-
ample, as successions of straight line segments. In TEMPO they can
also be defined in terms of algebraic operations on previously defined
functions (vectors) and on scalar quantities. Finally, they may be de-
fined in a CONSTRUCT-block, where each segment is specified in
the manner of a free CONSTRUCT statement.
The features described thus far incorporate new, more conven

modes of specification, but they reflect no great increase in capab
with respect to previous sound-generation programs. We now
ceed to describe a set of features which provide significant new c
bilities for automatic generation of the performance file or scor
Before describing these features it is necessary to point out th
whatever the importance and meaning of the notion "computer
position," that notion plays no direct part in the present exposit
By any reasonable delineation that might be supposed to exist
tween computer composition and human composition, either or b
can draw upon capabilities for automatic score generation.
The venerable musical idea of a set of events, and a transforma
upon that set of events, has been embodied in other systems. In
various Music IV and V systems, it is present in the form of
stored note-card image and the first-pass subroutine. The standa
procedure has been to define a set of potential notes by means of
and/or program, optionally to transform that set by means of a
routine, and finally to create actual notes by output to a file conta
performance data.
This capability is greatly expanded in TEMPO. A set may be
fined in terms of elements which are themselves sets. In this case
constituent subsets may be identical to previously defined sets, or
may be transformed versions of those sets. Each subset carries a r
120
tive action time (explicitly declared or defaulted to zero

a new set is defined in terms of existing sets, three
brought into play: collection, transformation, and distri
time. All of this is best clarified by means of examples.
The following SET-block defines a set named SET1:

SET SET1;
AT 0 PLAY TRIVIAL FOR 1: 1.0, 100;
END;
The following TRANSFORM-block defines a transformation

named TR1 which could be performed on SET1 and other sets:
TRANSFORM TR1 (ARG);
LET &(*, 1)= &(*, 1) *ARG;
END;
The symbol &(*, 1) is a specific case of the general symbol &(m, n),
which refers to the nth parameter in the mth PLAY statement of a
set to be transformed. In the symbol &(*, 1), "*" indicates a loop over
the possible range of the subscript for the set to be transformed.
Thus, the LET statement directs that the first note parameter be
multiplied by ARG (with the result replaced in the first note para-
meter) for each PLAY statement in the set. For example, if ARG
has a value of 100, and TR1 is applied to SET1, the resulting trans-
formed set will be equivalent to the following:
AT 0 PLAY TRIVIAL FOR 1: 100, 100
AT 0 PLAY TRIVIAL FOR 1: 120, 100
AT 0 PLAY TRIVIAL FOR 1: 180 100;
Thus the trichord represented by SET1 may be located at any de-

sired base frequency by invoking TR1 as a modifier of SET1 with t
appropriate argument.
It should be explained here that the actual invoking of a transform
always takes place with reference to a specific set, the contents an
dimensions of which are available to the transform automatical
This information is referenced within the transform by variables wi
preassigned names beginning with the character "&."
A more powerful transform is the following:
TRANSFORM TR2(ARG1, ARG2, ARG3); (1)
OLDLEN = &LENGTH; (2)
&LENGTH = &LENGTH + &LENGTH*ARG1; (3)
* 121 ?
1I = OLDLEN + 1; (4)
DO 12 = I1, &LENGTH; (5)
13= 12 -OLDLEN; (6)
LET &(I2, &START) = &(I3, &START) + ARG2 (7a)
&(I2, &DUR)= &(I3, &DUR) (7b)
&(I2, &INSNO)= &(13, &INSNO) (7c)
&(I2, 1) = &(I3, 1)*ARG3 (7d)
&(I2, 2)= &(I3, 2); (7e)
DONE; (8)
END; (9)
Statemen
transform
the set b
In filling
remaining
length OL
statement
statemen
PLAY stat
In statem
the action
strument
than the
from the
first note
previous g
parameter
ment (8) c
By way o
TR2 is ap
the result
AT 0 PLAY TRIVIAL FOR 1: 100, 100;
AT 20 PLAY TRIVIAL FOR 1:145.8, 100;
From the foregoing, it should be clear that a set is a kind of macro-

event, and a transform a kind of modifier for a macro-event. A trans-
* 122
form may also be thought of as a function which define

pondence between the domain of macro-events upon whic
to operate and the range of macro-events which it can o
Now suppose that, in addition to SET1, the program
defined SET2, consisting perhaps of a tetrachord tha
against the trichord of SET1 in various ways. (We nee
SET2 here, for its precise contents do not matter.) The p
could then state:
AT 0 PLAY (TR1 (100) OF SET1);

AT 2 PLAY (TR1 (200) OF SET2);
This simply causes the two chords to sound one after the other with
base frequencies of 100Hz and 200Hz, respectively. The sets are
transformed by TR1 as specified and the results are output to the
performance file.
The outer set of parentheses in each of the statements encloses
what is known in TEMPO as a phrase; the statements as a whole are
phrase-type PLAY statements, as distinct from single-note PLAY
statements.
A higher order set defined in terms of existing sets is cal

to reflect the fact that it is not immediately expanded in m
is retained there as a string of defining symbols, in order
storage.
The first statement below defines a string named S1, in
SET1, SET2, and TR1. X, Y, and Z are dummy arguments w
ceive values only when the string is activated by the subseq
statements referencing S1.
STRING S1(X, Y, Z)=
(AT 0 TR1 (X) OF SET1)
(AT 2 TR1 (Y) OF SET2)
(AT 3 TR1 (Z) OF SET1);
LET K1 = 200 K2 = K1:*1.5 K3 = K1*2 L = 1.9;
AT 5 PLAY (S1(K1, K2, K3));
AT 10 PLAY (S1 (K1*L, K2*L, K3*L));
The first of the above PLAY statements results in the equivalent o

the following output to the performance file:

(4 PLAY statements from the 2nd phrase of S1)
123

Each of the two phrase-type PLAY statements is thus expanded to

10 single-note PLAY statements. By simply changing the values of
K1 and L in the LET statement, the programmer can affect the action
times and first note parameters of all 20 events.
In the following series of statements strings S2 and S3 are defined
and S3 is referenced by a PLAY:
STRING S2(ADD1, ADD2, INT, LAG, X, Y)=
(AT 0 TR2 (ADD1, LAG, INT) TR1 (X) OF SET1)
(AT 4 TR2 (ADD2, LAG, INT) TR1 (Y) OF SET2);
STRING S3(X, Y, Z, ADD1, ADD2, INT, LAG)=
(AT 0 S1(X, Y, Z)
(AT 4 S2(ADD1, ADD2, INT, LAG, X, Y);
PLAY (S3(200, 300, 400, 2, 5, .9, .1));
In the definition of S2 each of the two phrases specifies that TR1
and TR2, in that order, are to be applied to a set. First TR1 places
frequency specifications in first parameter locations, and then TR2
expands the set. The first phrase in S2 represents the 3 events origin-
ally in SET1 plus (ADD 13) events, or a total of 3-(ADD1 + 1) events.
Similarly, the second phrase in S2 represents 4-(ADD2 + 1) events.
Thus, string S3 represents the 10 events of S1 plus the number of
events in S2, as noted above. Since the given PLAY statement assigns
values of 2 and 5 to ADD1 and ADD2, this statement expands to 43
single-note PLAY statements. (10 + 3-(2 + 1) + 4-(5 + 1) = 43.)
Occasionally, the same sequence of transforms may be required in a

number of STRING or PLAY statements. To avoid writing out the
sequence each time, the programmer may define a word:
WORD W1 (X, Y)=
TR4
TR3(X)
TR2 (A)*4
TR1(B, Y);
In the above, X and Y are dummy arguments since they appear on

the left of the equal sign. A and B are compiler variables. "*4" is a
repeat constant directing that TR2 be applied 4 times in succession.
Having defined W1 in this way, the programmer realizes a consider-
able saving of effort in writing a series of statements such as the
following:
124
LET A= 1, B=2, X=3, Y=4;

AT 0 PLAY (W1(X, Y) OF SET);
LET X = 5, Y = 6;
AT 10 PLAY (W1 (X, Y) OF SET);
LET X = 7, Y= 8;
AT 20 PLAY (W1 (X, Y) OF SET);
Obviously, through pyramiding of string and word definitions

and through the use of transforms which expand sets, it is easy
to arrange to create hundreds, even thousands, of events with one
PLAY statement. (For that matter, it is theoretically possible to pro-
gram any given piece in TEMPO in such a way that the entire per-
formance file is created by an all-powerful PLAY at the end of the
program.) Equally obviously, there is as much potential for evil as for
good in this possibility. The author strongly suspects that the power in
the string and set-expansion features of TEMPO will play a major
role in the best and worst musical features of works produced with
the language.
Such complexities as the string and word features may seem for-
bidding to some readers. Indeed, the language will probably acquire
additional potential for complexity if and when additional features
are implemented, such as array data types, reading of external files,
and iteration and conditional branching among free statements.5
However, one of the design goals of TEMPO has been to preserve the
possibility of easy use of limited sets of the language's capabilities. It is
anticipated that many TEMPO programs will consist largely of IN-
STRUMENT-blocks, single-note PLAY, and free CONSTRUCT
statements. Additional complexities can be added to a program, and
fuller use of the language facilities can be undertaken by a pro-
grammer, as musical needs dictate. In this way, it is hoped that
TEMPO will be suited equally well to the requirements of beginning
and advanced practitioners of computer sound-generation.
5 Another kind of extension is not really an enlargement of the language proper and
should take place on a continuing basis. This is the addition of new unit generators and
function generating routines, full and varied sets of which are desirable for any im-
plementation of TEMPO. In practice, these will vary from one implementation to an-
other, as dictated by local requirements and interests.
* 125 ?

Perspectives of New Music Perspectives of New Music

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Perspectives of New Music Perspectives of New Music

Uploaded by

Copyright:

Available Formats

TEMPO: A Composer's Programming Language

Author(s): John Clough

TEMPO: A COMPOSER'S PROGRAMMING

TEMPO (Transformational Electronic Music Process Organizer) is a

1This implementation will be generally compatible throughout System 360. An

duce concepts which played a part in its design and to

Programs such as the Bell Telephone Laboratories'

There are three passes in the complete execution of a program in

Pass 1 input is a program in TEMPO. Its output is the perfor

performance file, but do not themselves create such outpu

Compiler elements Performance elements

Though compilation precedes performance in the processing of a

Instruments can be thought of as complex operators or subroutines.

A note is a collection of numeric quantities describing

A transform is analogous to a subroutine. After it is initially processed

LET X= 12; (1)

Statement (1) defines a comp

In general, any numeric quantity in TEMPO may be a

A TEMPO program consists of free statements and

An INSTRUMENT-block defines an instrument in terms of unit-

Since the pivotal entity in the execution of a program

INSTRUMENT TRIVIAL: PITCH = &P1 ACCENT = &P2; (1)

The OUTPUT statement simply evaluates the given expressio

Following is a block diagram of TRIVIAL:

V .01 .01 LOUDNESS ACCENT

AT A + 14 PLAY TRIVIAL FOR 1.5: 440, 100;

A A + 14 P 1 F 1.5: 440, 100;

However, the printed output of TEMPO displays the unabbreviated

written by the programmer. For the sake of consistency, th

The features described thus far incorporate new, more conven

tive action time (explicitly declared or defaulted to zero

The following SET-block defines a set named SET1:

The following TRANSFORM-block defines a transformation

Thus the trichord represented by SET1 may be located at any de-

From the foregoing, it should be clear that a set is a kind of macro-

form may also be thought of as a function which define

AT 0 PLAY (TR1 (100) OF SET1);

A higher order set defined in terms of existing sets is cal

The first of the above PLAY statements results in the equivalent o

AT 5 PLAY TRIVIAL FOR 1: 200, 100;

AT 8 PLAY TRIVIAL FOR 1: 400, 100;

Each of the two phrase-type PLAY statements is thus expanded to

Occasionally, the same sequence of transforms may be required in a

In the above, X and Y are dummy arguments since they appear on

LET A= 1, B=2, X=3, Y=4;

Obviously, through pyramiding of string and word definitions

You might also like