PDF

Yale University Department of Music
Music Analysis and the Computer

Author(s): Raymond Erickson
Source: Journal of Music Theory, Vol. 12, No. 2 (Winter, 1968), pp. 240-263
Published by: Duke University Press on behalf of the Yale University Department of Music
Stable URL: http://www.jstor.org/stable/843312 .
Accessed: 09/12/2014 18:59
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 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.
Duke University Press and Yale University Department of Music are collaborating with JSTOR to digitize,
preserve and extend access to Journal of Music Theory.
http://www.jstor.org
This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

All use subject to JSTOR Terms and Conditions
240
Music Analysis
and
I. INTRODUCTION *1
In spite of the ever-increasing use and acceptance of modern

data processing equipment for humanistic research, there would
appear to be, judging from one stormy session at the national
meeting of the American Musicological Society at Santa Bar-
bara in 1967, a widening gulf between scholars who pursue the
traditional methods of historical musicology and those who have
adopted the computer as their chief research tool. This un-
fortunate and unnecessary division stems largely from a mis-
This article originally appeared in Computers and the Humani-

ties Volume III, No. 2 (November 1968). This expanded ver-
sion is published by permission.

241
the Computer
RAYMOND ERICKSON
understanding of the nature and limits of computer-aided schol-
arship by the former group; however, the situation is hardly
assuaged by members of the other camp who are often unwilling
to discuss their work in terms intelligible to the uninitiated.
The problem has been further aggravated by the fact (noted by
Harald Heckmann in his preface to one of the books discussed
below) that musicology was one of the last humanistic disci-
plines to recognize the potential usefulness of twentieth-century
technology. To be sure, significant forays into bibliographic
control and computer composition have been made in recent
years, but what is surely one of the most fertile and extensive
territories, that of musical analysis, still remains largely un-
explored. While it has been adequately demonstrated that a
computer can be programmed to count eighth-notes or deter-

242
mine pitch-class distributions, there are as yet no standard

for the encoding of music, no generally available musical anal-
ysis programs (as there are, for example, statistical program
"packages"), and no comprehensive theoretical system for
computer-aided analysis. Nonetheless, the past few years
have seen a marked increase in the quality of work in the field
and we can look forward to the publication of significant com-
puter-derived information about music in the not-too-distant
future.
To acquaint himself with what can be done and some of what

has been accomplished, the musical scholar would do well to
peruse two volumes of papers that have recently appeared.
Computer Applications in Music, edited by Gerald Lefkoff*2,
is a slim book of about 100 pages containing five papers pre-
sented at a conference at West Virginia University in April
1966. Despite great advances in computer technology since
that time, the articles are still relevant. They are expository
rather than technical and span most of the areas of computer
utility in music. This is an excellent introduction and should
be read by every musicologist, whether or not he himself is
contemplating the use of computers. Virtually free from the
technical jargon that can obscure the meaning of simple con-
cepts for the general reader, it can do much to close the "com-
prehensibility gap" that is needlessly dividing the ranks of mu-
sical scholars.
A larger set of papers, more varied both in content and quality,

is assembled in Elektronische Datenverarbeitung in der Musik-
wissenschaft, edited by Harald Heckmann. *3 This volume does
not attempt to address readers of any particular level of ex-
pertise, but simply presents a dozen contributions ranging from
the trivial to the sophisticated. *4
It is not my intention here to review the two publications as a

whole but rather to consider two papers from each dealing with
analytical topics. These provide sufficient material and object
lessons for a general report of the state of the art of musical
analysis -by computer. The projects to be discussed differ in
scope and approach; they will be evaluated partially in terms
of current trends in computer technology, the most relevant of
which will be subsequently summarized. Finally, on the basis
of these and other considerations, some guidelines and sugges-
tions for future work in this field will be offered. For the most
part, the commentary will be presented from a practical (i. e.,
programming) rather than a theoretical point of view, but will
be aimed at the scholar with limited experience with computers.

243
It is my feeling that, although the number of musicologists with

professional programming skills is now small, it is desirable
that every researcher have a general idea of the facilities avail-
able to him and their best possible use. Furthermore, it is
high time to recognize that a computer is not by nature a math-
ematical tool. This bias has hindered students of the humani-
ties who have tried to adapt their problems to the types of solu-
tions employed by scientists and engineers. *5
II. MUSICAL ANALYSIS BY COMPUTER: SOME GENERAL

REMARKS
Before delving into the particulars of the various articles, we

should consider some of the prerequisites for any computer-
aided *6 analytical study. One still hears the naive remark that
all that is necessary to solve this or that problem is to "run it
through a computer". The matter is not that simple, of course,
and it is safe to say that most serious undertakings will involve
years of work. It should be stressed, therefore, that a com-
puter may not produce a faster solution to a given problem;
rather, its unique value is in broadening the range of problems
that can be posed and solved. There are several reasons why
projects in musical analysis by computer may take considera-
ble time to conceive and execute, not the least being that analy-
sis must be preceded by the tedious and time-consuming prep-
aration, checking, and correction of data. Furthermore, the
expense, both in money and programming time, is often justi-
fied only when there is a large quantity of data to be processed.
Eventually we will have automatic scanning devices to assist

us in the preparation of data *7, but until then every system for
musical analysis will require the following:
1. An Encoding Language. Translation of the primary source

material into symbols available on standard keypunch machines
requires an encoding language. ,This language should be a
complete and closed system, permitting a virtual 1:1 corres-
pondence between the original and the associated encoded data.
Because certain kinds of source material present special
problems - the legibility of manuscripts, for example - pro-
vision should be made for the insertion of parenthetical com-
ments and/or variant readings.
One of the problems that has plagued musical research in re-

cent years has been the plethora of encoding languages. None,
however, offers the completeness of the Ford-Columbia lan-

244
guage, designed by Stefan Bauer-Mengelberg. *8 Intended for

use with a computer-driven music printer, it has become per-
haps the most widely used of the proposed encoding languages.
It should be pointed out that although the Ford-Columbia lan-

guage is isomorphic to traditional modern notation, a corres-
ponding system is lacking for the representation of Medieval
and Renaissance manuscripts and prints. However, given the
large number of changes in the notational forms of those peri-
ods, such a comprehensive code may not really be feasible. *9
2. Debugging and editing routines. Scanning the encoded data

for encoding errors and making specified corrections requires
programs for checking and editing. Ideally, a checking pro-
gram should verify the validity of every element in the data-
set. Just as there is really no reason to advocate "partial
encoding" for an analysis that aims at completeness, there is
equally little justification for allowing any syntactic errors to
escape notice.
To design and build a syntax analyzer is a nontrivial task, but

the experienced programmer can profit from a study of syntax-
directed compilers. In general, permissible syntactic struc-
tures are defined in some formalized grammar, such as Backus
Normal Form, and placed in a syntax table. A recognizer rou-
tine then isolates tokens in the input string *10 and passes them
to the analyzer routine, which verifies their validity with res-
pect to the tabled specifications or prints an appropriate error
message. This presupposes, of course, a precise formulation
of the encoding language. *11
Since the data must be not only valid in format but also correct
in content, one must always be resigned to the necessity of a
final comparison with the original source material before pro-
ceeding to the next stage.
3. Analysis routines. These are determined by the internal

form of the data and the nature of the analytical procedures.
In most cases the input will be a string of characters which
will then be parsed to separate out various classes of events,
which are then arranged in more workable and easily refer-
enced data-structures. These are then left in the computer
memory, or preserved on disk ortape for later use. Depending
on circumstances the parsed data could be stored in arrays,
strings or list structures. The actual analysis would then
operate on the data thus represented.

245
For those unfamiliar with the characteristics of these data

structure types (users of FORTRAN*12, for example, would
find string manipulation and list processing awkward and im-
practical), let us posit the existence of a data-set (say, a move-
ment from a Haydn string quartet) encoded in the Ford-Colum-
bia language. Such a data-set is read and stored initially as a
"string", i. e., a continuous stream of alphanumeric charac-
ters. The stored string can then be parsed on the basis of the
Ford-Columbia instrument codes indicating the beginning of a
segment of a given instrumental part, which segment is then
concatenated with previously extracted segments of that instru-
mental part. The result is, of course, four sub-strings, each
containing the complete part for one instrument.
The parsing can be carried to further levels by deleting specific

kinds of information (meter, key, pitch-codes, duration codes,
etc.) from the four sub-strings and storing them in tables or
"arrays* with the columns indexed by temporal position within
the composition and the individual rows containing, for exam-
ple, absolute pitch values, pitch-class values, intervallic suc-
cessions, duration values. Most of these and other parameters
that might be desired are easily calculated and stored. It might
be added that tables of this sort (cross-indexed with respect to
temporal position in the score) permit very fast retrieval of
information. Programs which use them as data are known as
"table-driven" programs.
Once the tables are compiled, the analysis proper can begin.
Let us say that in an examination of melody segments it is dis-
covered that melodies B and C incorporate the test pattern A
as a beginning and that D and E begin with melody segment C.
This can be done simply by comparing the intervallic succes-
sions calculated for each segment in the tables cited above. A
"tree" or "list" (whose elements might be names of, or point-
ers to, the specific melodic segments) can be created in the
course of this analysis to preserve these relationships for later
consideration. A diagrammatic representation of such a data-
structure might look like this:
List structures have obvious relevance to the formation of

manuscript trees according to variants and to the computer
implementation of Schenkerian analysis.

246
Programming languages have been designed for each type of

internal representation, although none handle all types with
equal facility. However, as will be seen below in the review
of current trends, the situation is improving steadily.
III. SOME COMPUTER-AIDED PROJECTS IN MUSICAL

ANALYSIS
The novice who is looking for a lucid, non-technical introduc-

tion to our topic need only turn to Allen Forte's neatly organ-
"
ized article "Computer-Implemented Analysis of Musical Style
(Lefkoff, pp. 31-42). Brief and pithy, it takes into account
those problems best suited to computer solution and provides
a useful classification of high-level programming languages
according to the data-structure types they are designedto ma-
nipulate. There is also a brief summary of his own then cur-
rent work, a score-reader program for atonal music. The
results of this project have since been more fully documented.
*13
One of the lessons to be learned from Forte's research is that

rigor of thought and definition is of far greater importance than
an intimate technical knowledge of the internal workings of the
machines used. This is not to deny the value of the latter nor
to suggest that Forte does not possess it. The point is that he
has limited his programming to high-level languages already
available and, armed with the power they provide, he has at-
tacked specific musical problems with considerable success.
A further advantage of programs in high-level languages is
that they are relatively machine-independent and can be run on
other computer systems with slight modifications.
It may be that theorists will take exception to the description

of atonal music that Forte will achieve upon the completion of
his present study, but there is little to criticize regarding the
role and use of the computer. It is perhaps unfortunate that
the new programming language PL/I was not available to him,
since its capacity for handling character strings as array ele-
ments would certainly have simplified certain aspects of the
score-reader program (written in SNOBOL3) and made it un-
necessary to resort to another language (MAD) for subsequent
analysis procedures. A rigorous analyzer for checking data
encoded in the Ford-Columbia language (Forte being a long-
time proponent of the Bauer-Mengelberg system) would also
seemto be preferable to a routine that scans "for certain kinds
of encoding errors". It should be understood that these sug-

247
gested improvements for an otherwise model study would not

change the results of that study but would rather facilitate
reaching them. I stress the need for a general syntax analy-
zer for Ford-Columbia data-strings - which, to encourage wide
implementation, should be written in a high-level program-
ming language - because it could be a powerful force in bring-
ing about adherence to a single encoding standard that many
(myself included) regard as highly desirable.
A nice companion article to Forte's general introduction is

"Computers and the Study of Musical Style" by Gerald Lefkoff
(Lefkoff, pp. 45-61). The paper focuses on "compute r-residing
models and their use in the study of style", and details how a
single data-type (the array) and a programming language de-
signed to handle it (FORTRAN) may be used in musical studies.
The internal representation of information for his MUSTUD
system is much along the line of that suggested by the use of
tables in the hypothetical example given above:
The various kinds of information contained in the score

are separated and stored in independent arrays which
are cross referenced to a time index. The time index is
a one-dimensional array with the subscript indicating the
ordinal location of the event and the stored value indi-
cating the location in continuous time measured in quar-
ter notes. The pitches are represented in a two dimen-
sional array with each voice assigned a location in the
array. The values stored in one column indicate the or-
dinal location of the pitch event referencing the time in-
dex array, and the values stored in the corresponding
row of another column represent the concert pitches.
Other arrays arranged in the two dimensional manner of
the pitch array may be used to list vocal text, figured
bass symbols, dynamics and articulations, and editorial
comments. (pp. 46-7)
This method of stratifying and indexing the various attributes

simplifies retrieval greatly and allows for contextual examin-
ation of what Forte would probably call "event configurations"
*14 and the extraction of what Lefkoff calls "model segments",
since he considers the arrays to be models representing as-
pects of the original score.
Considering the relatively limited objectives of Lefkoff's anal-

ysis, I will not quibble about the use of FORTRAN except to
note that the weaknesses of that programming language prob-
ably affected the encoding system that Lefkoff developed for

248
his project. However, I do fail to see how introducing the con-

cept of a model with respect to the internally stored array
helps our understanding of the musical problems, since it is
obvious that all internal data-structures (arrays, strings, lists,
etc.) are in some sense models of external raw data. As I see
it, the discussion would have been more profitably directed to
a consideration of how a much more basic model - the encoded
version of the source material - might best be designed. Lef-
koff uses a special 80-column coding sheet (Lefkoff, p. 49) to
record various attributes of individual notes, one line of 80
columns for each note. Data in this form is easy to keypunch
(and proofread) and can be read directly into the proper inter-
nal arrays by using a single format specification withl the ap-
propriate input statement (a facility by no means unique to
FORTRAN, incidently). However, even if not all classes of
attributes of the musical score are needed for a particular
study, I doubt whether using the Ford-Columbia language would
have increased encoding time, and the result would have been
a more complete and accurate model of the object of study. Of
course, if SNOBOL or MAD (in which character manipulation
is less awkward than in FORTRAN, which MAD resembles in
many ways) were not available to him, one can understand his
avoidance of data in string form.
If I have reservations about Lefkoff's encoding principles and

even question whether the explicit emphasis on musical models
really contributes anything significant to the end results of his
work, I am also much impressed by his descriptions of several
analysis algorithms which exemplify very well the kind of pro-
cess that must be programmed in order to best utilize the power
of the computer. Illustrated are the derivation of various types
of melodic transformations, the determination of frequency
distribution of items within a class, and suggestions of how one
might approach problems involving several stylistic parameters
and/or several groups of data. Some notion is also given of
how information can be stored on tape and retrieved. Imple-
rnenting these processes is not difficult in any sense, but not
all problems whose solutions are facilitated by computer im-
plementation require sophisticated programs. For this reason
Lefkoff's paper should be of particular value to the novice.
Certainly the most ambitious undertakings in musical studies

from a programming point of view are the systems for musical
analysis discussed by Eric Regener and Tobias P. Robison,
both graduate students at Princeton when the articles were
written. In spite of Regener's elegance of style and Robison's
extended introduction, the inexperienced reader may have some

249
trouble following their respective presentations, so it seems

worthwhile to briefly describe and compare the two projects.
In "A Multiple-Pass Transcription and a System for Music

Analysis by Computer" (Heckmann, pp. 89-102) Regener de-
scribes the design and operation of SAM (System for Analysis
of Music). It consists of the following components:
1. A multiple-pass transcription code designated LMT (Linear

Music Transcription). The encoder reads through the score
several times, first recording in code the durations, then
pitches, text, literal information, and finally alternate and
variant readings.
2. An elaborate 2-stage assembler program written in FAP,

an assembly language for the IBM 7090 family of computers.
Stage I consists of these several blocks of coding:
a. Input routine
b. Abbreviation decoder
c. Symbol recognizer
d. Syntax routines
e. Output routine that creates intermediate table on tape
f. Error routine to be called when syntax routines find
an invalid symbol
Stage II proceeds as follows:
a. Intermediate table is read from tape, rhythm pass

first;
b. Notes are indexed by attack time, then
c. Succeeding passes are read in and combined with
previously assembled material to produce the final
table.
The completed table is made up of 4 types of information, the

type being indicated by the leftmost 3 bits of a 36-bit computer
word, and the actual information being contained in the re-
maining 33 bits. A portion of the table beginning at memory
location L and representing, say, three notes of the same at-
tack time, two on one stem and one on another, might look
something like this:
L Oxx ATTACK TIME VALUE

L+1 111 STEM(1) INFORMATION
L+2 110 PITCH(a)INFORMATION

250
L+3 110 PITCH(b) INFORMATION

L+4 111 STEM(2) INFORMATION
L+5 110 PITCH(c) INFORMATION
ATTACK TIMES are computed as floating-point numbers; since

they will always be positive, the sign bit (the leftmost bit) will
always be zero. STEM information includes appropriate voice
and part numbers, tie indicator, preceding-barline indicator
and numerical references to the table of durations and to the
table of text syllables. NOTE information includes pitch, num-
ber and types of accidentals, etc. A fourth word type, SUB-
SIDIARY, can follow any of the above types with qualifying in-
formation such as fermatas, time-signature changes, articu-
lation marks, etc.
3. Two external subroutines to be used in conjunction within-

dependent analysis programs written by the user. These sub-
routines are:
a. an initialization routine to read the table from tape

into core storage, and
b. a retrieval routine to return values specified by (up
to) four arguments (attack time, part and voice num-
bers, and a keyword indicating the type of information
desired).
Once this information is available to the calling program (written

in any language, such as FORTRAN or MAD, compatible with
these special subroutines), the individual programmer may
manipulate it in any way he wishes.
Even more ambitious in scope than SAM is the system described

by Tobias P. Robison, who gives a full and often technical de-
scription of his undertaking in "IML-MIR: A Data-Processing
System for the Analysis of Music" (Heckmann, pp. 103-35). The
encoding language developed for the project is a one-pass lan-
guage called IML (Intermediate Music Language); data coded
in IML is compiled into tables which are then written on tape
by system programs that perform much the same function as
Regener's assembler. The actual analysis programs, how-
ever, are not to be written in any general multi-purpose lan-
guage such as FORTRAN, but in MIR, a special high-level
language devised for this purpose.
MIR was designed in the belief that other programming languages
were awkward for problems in musical analysis, particularly

251
when there were few experienced programmers in the musico-

logical community. Consequently, every effort was made to
produce a language as powerful as possible, but with a minimum
of grammatical rules to be followed. In this, Michael Kassler,
the chief architect of the IML-MIR system, and Robison, who
modified MIR somewhat in the course of implementing it on the
IBM 7090, were quite successful.*15 It should be added here
that responsibility for the completion of Robison's task has re-
cently been assumed by Mr. -John Selleck.
A MIR program consists of a series of instructions that may

be of four types:
1. "Orders" determine the sequence in which notes and rele-

vant information (title, measure number, accidental-type, etc.)
become current. For example,
TOTITL (arg)
makes a new composition (and also the first note of the top
part) current. The argument embodies a specific title name in
parentheses; if absent, the IML tape is moved to the next com-
position in sequence. *16
TONOTE [arg]
finds the next note in the current context if there is no argu-

ment. An integer argument n specifies the nth note within the
particular measure but when preceded by a plus or minus sign
indicates the nth note to the right or left, respectively, of the
current note. When a note becomes current, all its attributes
are accessible to the program.
2. "Operations " manipulate current information by performing

assignments, arithmetic operations, and input-output. For
example,
MOVE A, B
assigns the value of A to B,
ADD A, B, C
adds A and B, storing the result in C; finally
MPRINT (arg list)

252
prints the categories of current information specified by the

argument list.
3. "Tests" compare items of current and saved information.

For example,
CMPAR TIEIND, TIE, NINE
tests the tie indicator; if on, control is transferred to the state-

ment labeled NINE.
4. "Declarations" define temporary work areas, like the DI-

MENSION statement in FORTRAN or MAD. For example,
DEFINE (A(12), B(5))
reserves 12 storage locations for the variable A and 5 for the

variable B.
The simplicity of programming in MIR may be illustrated by

the (admittedly trivial) program adapted from the article shown
in Example 1.
By taking advantage of the BEFAP macro facility, the imple-

mentors of MIR have:
1. Simplified programming from the user's point of view, al-

though MIR is actually a lower-level language than, for exam-
ple, FORTRAN;
2. Provided for the addition of other instructions or routines

in assembly language by the knowledgeable user;
3. In effect, created a MIR machine, whose basic character-

istics are defined by the series of pre-defined macro-instruc-
tions, i.e., the MIR commands.
The Regener and Robison articles provide us with a number of

valuable insights and ideas. Regener's multiple-pass encoding
language is a clever solution to the problem of what to dowhen
immediate needs call for only durations and pitches. When
one leaves out information in one-pass languages, it is irre-
trievably lost; with LMT, the user merely adds another "layer"
of information without changing any of the previously encoded
data. There is also something to be said for being able to use
any of several programming languages to manipulate the data
tabled by the SAM assembler.

Statement
Label Instruction Operands Explanation
START TOCOMP 2 Find second composition on IML tape.
The first note and all its attributes are
automatically made current.
ONE MOVE DUR, WA1 Store duration of current note in Work
Area 1. (The 20 Work Areas function as
general purpose registers.)
TWO TONOTE +1 Make next note (same part of same com-
position) current.
CMPAR DUR, WA1, TWO If duration (DUR) of current note is same
as that of previous one (now stored in
WA1), transfer to TWO. If not, execute
next instruction.
MPRINT (MEASNO, NOTENO, DUR, TEXT)
Print the measure number, note number

within measure, duration and text asso-
ciated (if any) for current note.
GOTO ONE Transfer to ONE.
ENDRTRN DONE When end of IML tape is reached, trans-

fer to DONE.
DONE FINISH Terminate program.
END No more cards follow.

254
The appendix of the Robison paper, on the other hand, which

contains a description of all the MIR commands, provides a
handy and reasonably complete checklist for anyone writing a
library of analytical functions for music analysis. The wise
programmer will seek to reduce these functions to their most
basic form, just as Robison, Kassler and Selleck have done,
so that they can be used as building blocks for complex analyti-
cal procedures.
Singularly ironic though it be, it is precisely the high level of

programming competence evident in the design and execution
of both SAM and IML-MIR that has produced the one major flaw
in these systems: machine dependence. Both were written in
assembly language for the IBM 7090 (or 7094), which is gradu-
ally being replaced by "third-generation" computers such as
the IBM Series 360. This relative usefulness of the system to
the availability of a particular computer model, plus the fact
that it has taken several years for professional programmers
like Regener, Robison and Selleck to produce working systems,
points up well the liabilities of using machine and assembly
language for anything but the most general applications. *17
The situation is not quite as grim as it first appears, however,

since the IBM 7090 and its faster twin, the 7094, will be around
for several more years. Delivery of the newer machines is
slow, and few installations will simply push the old model out
the back door as the new machine is rolled through the front; it
is an arduous task to convert standard programs for use on a
different machine. In addition, manufacturers now sell emu-
lators for third-generation machines which execute programs
written for older ones (see below). And since the logical prob-
lems of design have been worked out, it is possible for SAM
and MIR to be rewritten in another, preferably machine-inde-
pendent, language.
IV. IMPLICATIONS OF TECHNOLOGICAL ADVANCES FOR

SCHOLARSHIP IN THE HUMANITIES
It seems fitting that this report include a review of some of the

more important developments in computer technology that will
affect the work of almost every user now and in the near future.
The potential of none of these areas is adequately covered in
either of the volumes discussed above, an indication of the
speed of change in the computer world. But the fact remains
that facilities merely talked about two years ago are with us
now and thus we must reckon with their implications. The ad-

255
vances most relevant to the researcher in the humanities come

under the headings of time-sharing, microprogramming and
programming languages.
A. Time-sharing. Undoubtedly the most dramatic of these

new concepts is time-sharing, which provides seemingly simul-
taneous use of all the resources of the computer system by
many individual users. The main memory of such a system is
divided into a number of partitions, each holding the program
and data designated by one user "logged-on" to the system;
since there is but one central processing unit (the CPU being
the actual "computing" part of a computer), only one program
can be in execution at a given moment. However, by means of
multiprogramming, control can be and is transferred to an-
other as soon as an "interrupt" occurs within the program cur-
rently being executed. Interrupts may be caused by many con-
ditions, such as reaching a maximum time limit (e. g., one-
tenth of a second) while executing a given program without en-
countering other interrupt conditions; a more likely occurrence
would be an input or output request requiring the use of an ex-
ternal I/O device such as card-reader, terminal, tape unit,
etc. Without multiprogramming, the CPU would have to wait
for the completion of certain I/O operations, however, this
waste is eliminated by the immediate transfer of control into
the next program according to priority while the I/O device is
simultaneously activated. Thus programs are not executed
from beginning to end but rather in slices, while control travels
from one partition to another. However, the speed with which
interrupt conditions are raised and handled makes it seem as
though an individual user, usually seated at a remote tele-
typewriter terminal, were the only one connected to the com-
puter.
Time-sharing also involves the concepts of interaction and files.

The former concerns the intimate man-machine relationship
made possible by the remote terminals. The terminal, not the
traditional card reader, now becomes the normal means of en-
tering programs and even data (although all the old modes of
communication are still possible). These data-sets may be
created, edited, deleted and even shared with other designated
users by means of simple commands given via the typewriter.
Auser may also interrupt a program in the middle of execution
just by pressing a button. (How many times have we remem-
bered a correction to be made just after submitting a job for
processing!) Since data-sets might never take card form they
are normally named and stored as files on an external storage
device (normally disk). The executive program of the system

256
keeps track of and protects each user's catalog of files; the

files themselves can be retrieved almost instantly by the user
whenever he or one of his programs has need of them.
There are many advantages of a time-sharing system, one be-

ing the virtual elimination of "turn-around time" - the interval
between job submission and availability of results, often hours
in many computer installations. Furthermore, it is much
easier and faster to edit programs and data from the terminal,
thus significantly shortening the time required to debug pro-
grams.
B. Microprogramming. A microprogram may perhaps be best

understood as a series of steps (micro-instructions) which
cause the execution of a machine-level instruction. Up to now
these steps have been embedded in the permanent physical cir-
cuitry of computers and have defined and limited the operations
of the machine. The term "hardware has been used to denote
this circuitry and the physical components employed in its con-
struction.
In third-generation computers, microprogrammed logic is

more properly associated with the introduction of a changeable
"control store* which makes it possible to actually redefine the
characteristics of a given machine. Currently this can be ef-
fected simply by exchanging sheets of printed-circuitboards
containing encoded microprograms. However, the trend is
toward a rewriteable control store - a separate memory con-
taining microprograms in program form. Since microprograms
for such a machine will be loaded into the control store in much
the same fashion as "normal" programs are loaded into the
mainmemory of the computer, the previously clear distinction
between "hardware and "software* no longer obtains. The
term "firmware" has been introduced to designate this middle
ground. 4*18
For the non-scientist especially, the implications of micro-

programming are staggering. The mathematically oriented
instruction sets now available could be replaced with others
designed primarily for, say, character string manipulation or
list processing. Those of us interested in more powerful tools
to work with in these areas would thus do well to make our
needs known to the industry, which is always receptive to ideas
that might result in an expansion of areas of computer applica-
tions. The compiler writer also would benefit from this kind
of instruction set since it simplifies programming problems
tremendously, as would the user of high-level languages, who

257
stands to save large amounts of execution time and, therefore,

money.
Microprogramming also makes possible the emulation of one

machine on another. To take a specific case, it is now possi-
ble to obtain a set of microprograms for the IBM 360/ 65 which
will cause it to act like the IBM 7090 or 7094 from the pro-
grammer's point of view. This is why the work of Regener and
Robison is not in one sense as machine dependent as it might
appear, although by the same token it is not clear how many
installations would support a 7990-94 emulator on another ma-
chine. (It also might be observed that Kassler's MIR machine
could be emulated directly on a third-generation machine if the
latter were supplied with a set of microprograms corresponding
to the MIR instructions. This is unlikely, to be sure, but defi-
nitely possible.)
C. Programming Languages. At the time Robison and his

associates began to develop MIR, advances in software lagged
considerably behind those in hardware. FORTRAN, for exam-
ple, was and still is ill-adapted to non-numerical problems or
to situations in which the primary data-structure is the list or
string. Computer programmers in many non-scientific fields
realized this and began to produce an abundance of special pur-
pose languages to fill their particular needs; thus a program-
ming language for musical analysis was thought to be useful
and perhaps even necessary for computer-aided musical stud-
ies. Since then, however, there has been an effort within the
industry to consolidate effort in the development of a few very
general multi-purpose languages, of which PL/I has already
established itself as the most important.
PL/I, thanks to the immense power and influence of IBM, is

gradually replacing FORTRAN as the lingua franca of pro-
grammers. It combines facilities of the three types of lan-
guages listed by Forte (Lefkoff, p. 35) into a single, more com-
prehensive language. PL/I thus handles arrays (the primary
data-structure of FORTRAN, MAD and other ALGOL-like
languages), trees and lists (LISP, SLIP, IPL-V), and strings
(SNOBOL and SNOMAD, the latter being a set of defined oper-
ators to be embedded in MAD) with relative ease. This writer
has found PL/I's ability to handle arrays whose elements are
variable-length strings to be particularly useful in his own
work, but the potential of the language is only partially ful-
filled at present. For example, while one can program SNO-
BOL-like operations (such as scanning strings for patterns)
in PL/I, one often requires several PL/I statements for each

258
SNOBOL statement. However, the addition of more powerful

string-manipulating functions to PL/I is currently under con-
sideration by the designers of the language and will probably
be accomplished sometime in the future.
No discussion of programming languages for research in the

humanities would be complete without mention of SNOBOL,
which is supported in one of two versions at most university
computer centers. SNOBOL3 was designed for second-gener-
ation machines and soon proved its power and flexibility in the
manipulation of data in string form. SNOBOL4, already im-
plemented on many third-generation computers, represents a
considerable advance on both fronts. Some of its more notable
features are the introduction of real number arithmetic, funda-
mental changes and extensions in the scanning and pattern
matching algorithms, and the ability to create arrays and list
structures. Because of many changes in syntax, programs in
SNOBOL3 are not compatible with the SNOBOL4 compiler-in-
terpreter. SNOBOL, in either form, is a relatively slow and
therefore expensive language to use. However, its simplicity,
tremendous power, wide implementation, and proven worth in
musical studies have qualified it as a basic tool for musicolo-
gical research.
At least passing mention should be made of APL, a language

designed specifically for interactive systems. It makes use of
a remote terminal with a special keyboard of Roman and Greek
characters which are used singly or in combination to specify
very powerful operations. Although designed for mathematical
applications and requiring an abstract mathematical approach
to programming, it has string manipulating power of consider-
able strength. *19 Furthermore, it is far faster than any other
language now used with time-sharing systems; since APL is an
"interpretive" language like SNOBOL, statements are executed
as they are encountered, without a previous time-consuming
compilation(an unfortunate but necessary aspect of PL/I). Al-
though the potential usefulness of APL for musical studies is
just now beginning to be evaluated, preliminary results have
been encouraging and suggest that the language be given serious
consideration for some future applications. *20
V. CONCLUSION
From the foregoing review of some computer projects relating

to musical analysis and a consideration of important technolo-
gical trends, it is possible to arrive at a few conclusions and

259
outline guidelines for future work.
A. Just as the computer field as a whole has recognized the

need for standardization of programming languages, so musical
scholars should recognize the obvious benefits of an encoding
standard, at least for modern printed music. For several
reasons - among then wide critical acceptance, comprehen-
siveness, the potential for printing in regular musical notation,
and the ever-increasing software and hardware facilities for
character manipulation - the Ford-Columbia language could
well serve as this standard. Lacking now is a formaldescrip-
tion of the grammar and syntax of that language. With this in
hand, standardization could be significantly furthered by a syn-
tax-analyzer to detect errors in data-sets coded in the language.
Such an analyzer, if widely available, would reduce duplication
of effort and encourage conformity to the standard. *21
B. Given the power, flexibility, and availability of multi-pur-

pose programming languages, there is no valid reason to en-
courage the development of new languages for musical analysis.
C. The inadequacy of FORTRAN for computer-aided studies

in the humanities should be more generally recognized. Its
adoption by non-scientists has been promoted mostly by scien-
tists and engineers who have found it ideal for their own work
but who do not fully comprehend the particular needs of others.
D. The acceptance of an encoding standard and the develop-

ment of software that is increasingly machine-independent will
make possible libraries of both encoded compositions and ana-
lytical subroutines which could be shared by many installations,
or eventually stored in some sort of central data bank. This
would also encourage collaboration on large projects, which,
for the most part, has been conspicuously lacking.
E. The efforts of musical scholars who are also proficient

programmers can be expended more and more in the formula-
tion and solution of specific musical problems, now that the
computer industry has provided them with adequate means.
Allen Forte's productive and sophisticated research exempli-
fies a refinement of the statistical approach which aims to de-
termine the relative importance of basic stylistic features of
various groups of musical data. Although the method is straight-
forward, it will probably produce results that are highly orig-
inal.
There is another tack to be considered: the computer imple-

260
mentation of existing theoretical systems (such as that of

Schenker), or the design of new ones under the influence of the
new technology (such as those of Kassler and Regener - and I
am not referring here to MIR or SAM). There is a danger,
however, that the System may become the end in itself, taking
so long to design and build that it is obsolete before it produces
significant results. Nonetheless, in a recent and pregnant ar-
ticle, Eric Regener argues convincingly for such theoretical
systems, even if they may prove to be useful only to a limited
number. *22
As a historical musicologist I am primarily interested in an-

swers to specific questions, and so I tend to the problem-
oriented approach represented by Forte. Although this method
is somewhat tied to the particular investigation being under-
taken, it does produce significant results without necessitating
the development of a comprehensive "system" for computer-
aided musical analysis. Nonetheless, recognizing both the
need for and the value of a general method applicable to most
problems of analysis, I look forward with considerable interest
to the fuller development of ideas lately nurtured at Princeton.
Perhaps a synthesis of the two approaches might be effected,
providing us with a tool general and powerful enough to permit
us to start thinking less about method and more about music.
R E F E R E N C E S
1 The author is indebted to Robert Rosin, Associate Professor of Engineering and

Applied Science at Yale University, for his advice on certain technical details.
A special expression of thanks must also go to Professor Austin Clarkson of the
Department of Music, Yale University, for his penetrating criticism and gener-
ous advice on matters of content, style, and form.
2 Gerald Lefkoff, ed. Computer Applications in Music. Papers from the West
Virginia University Conference on Computer Applications in Music (Morgantown,
West Virginia: West Vtrginia University Library, 1967), 105pp. For a critique
of the articles not discussed here, see Wayne Slawson's review of this volume in
the Journal of Music Theory 12(Spring 1968), 105-11.

261
3 Heckmann, Harald, ed. Elektronische Datenverarbeitung in der Musikwissen-

schaft (Regensburg: Gustav Bosse Verlag, 1967), 237pp.
4 A useful up-to-date bibliography is appended, which depends largely on another

bibliography, Writings on the Use of Computers in Music (Gary Berlind, ed.
Institute for Computer Research in the Humanities, New York University, 1966).
5 One might profitably consider the implications of the dictum that "A computer
is a symbol manipulator, period". We often forget that mathematics is but one
form of symbol manipulation; those who would regard a computer as a kind of
super desk calculator have too simplistic a notion of the real nature of a com-
pute r.
6 Allen Forte (Lefkoff, pp. 31-2) distinguishes between "computer-aided" studies
("in which the role of the machine is not predominant") and "computer-imple-
mented" studies (in which the computer "does the largest part of the work for
the researcher"). I eschew this kind of distinction because it obscures the fun-
damental fact that the individual is always ultimately responsible for the results
no matter to what degree he relies on machines for assistance. Thus I feelthat
a quantitative distinction is really unnecessary and potentially misleading. How-
ever, when we arrive at that inevitable day when the computer tells us how to
proceed, a qualitative distinction and appropriate terminology will be in order.
Until then, "computer-aided" seems to be a reasonable description of the work
undertaken by many of us who use machines to implement and test ideas con-
ceived in our own minds.
7 Although Barry S. Brook in "Music Bibliography and the Computer" (Lefkoff,

p. 14) estimates that such a scanning device will cost from four to five hundred
thousand dollars to develop, there is a good possibility that it will be developed.
8 Mr. Bauer-Mengelberg, President of the Mannes College of Music, New York

City, is a mathematician, programmer and musician. A very brief summary
of certain features of the Ford-Columbia language can be found in Harry B. Lin-
coln, "Some Criteria and Techniques for Developing Computerized Thematic
Indices" (Heckmann, pp. 59ff.). Other encoding systems are expounded in the
following articles: Barry S. Brook, "Music Bibliography and the Computer"
(Lefkoff, pp. 21-27; it includes an outline of his "Plaine and Easie Code for Mu-
sicke"); Murray Gould, "A Keypunchable Notation for the Liber Usualis" (Heck-
mann, 25ff.); Murray Gould and George Logemann, "ALMA, Alphameric Lan-
guage for Musical Analysis" (Institute for Computer Research in the Humanities,
New York University 1966); Nanna Scheidt and Bjarner Svejgaard, "Applications
of Computer Techniques to the Analysis of Byzantine Sticherarion Melodies"
(Heckmann, pp. 190ff.). Three other methods for digital representation of mu-
sical scores will be encountered below.
9 Withthe permission of Mr. Bauer-Mengelberg, I have modified the Ford-Colum-

bia language to accommodate the notation of medieval polyphony from the School
of Notre Dame. Although this derivative code is being used for a stylistic study
of organum purum only, it could be expanded to include at least some notational
systems of both earlier and later (i. e., Renaissance) periods. Like the Ford-
Columbia language it attempts to capture the graphic appearance of the source
material (here, manuscripts) with no "interpretation" on the part of the encoder.
10 Most encoding systems produce input data in the form of character strings; a
rare exception is the procedure adopted by Lefkoff (discussed below) to which
this example therefore does not apply.

252
11 For a fuller description of syntax definitions and analysis the reader is referred
to "Syntax-Directed Compiling", Proceedings of the Eastern Joint Computer
Conference, AFIPS, 25(1964), 31-57. The article is reprinted in Programming
Systems and Languages, Saul Rosen, ed. (New York: McGraw Hill Book Co.,
(1967), 264-97.
12 A list of commonly used programming languages and relevant bibliography is

given in the appendix.
13 Allen Forte, "A Program for the Analytic Reading of Scores", Journal of Music
Theory 10(1966), 330-63.
14 Professor Forte never does define "event configuration", so my use of the term
is based on inference.
15 Michael Kassler has given his own description of MIR in "Toward Musical In-
formation Retrieval", Perspectives of New Music 4(Spring-Summer 1966), 59-
67.
16 Mr. Selleck, who kindly spent several hours going over the design of the IML-
MIR system with me, has rewritten much of the original coding of the MIR com-
piler and, in the course of doing so, has modified several commands. For ex-
ample, the argument for TOTITL now may be only an actual title name or null;
a new command, TOCOMP, is similar to TOTITL except that its argument is an
integer n specifying that the IML tape is to be moved to the beginning of the nth
composition. In the Robison version both names and integers were acceptable
arguments for TOTITL.
17 According to information received from Messrs. Regener and Selleck, both sys-
tems should be operational by the time this article is published. Aspects of IML-
MIR are already being used in conjunction with a project, directed by Professor
Lewis Lockwood, which seeks to establish a chronology of the works of Josquin
based on stylistic trends.
18 For an informal survey of firmware applications now and in the near future see
Ascher Opler, "Fourth-Generation Software", Datamation 13(January 1967) 22-
4.
19 A proponent of APL has told me of a complicated algebraic parsing algorithm

that required 400 statements in SNOBOL3 but only 50 in APL.
20 I am indebted to Professor Harry B. Lincoln of the State University of New York

(Binghamton) for informing me of the experimentation with APL by Mr. Christian
Grange r, Professor Lincoln's research assistant and a professional programmer.
21 Mr. Bauer-Mengelberg has recetntly begun preparation of a canonical version of

the Ford-Columbia language.
22 Eric Regener, "Layered Music-Theoretic Systens", Perspectives of New Music,

5(Fall-Winter 1967), 52-62.

2 b3
APPENDIX
The purpose of this appendix is to list the principal multi-purpose programming

languages which are recommended for musical analysis (FORTRAN has been in-
cluded simply because it is the best known of all programming languages now in use)
and to direct the interested novice to some relevant introductory texts. References
which are not tutorial are so noted. It goes without saying that this list and its as-
sociated bibliography are extremely selective, and that no attempt at comprehen-
siveness has been made.
APL Iverson, Kenneth E. APL/360. The APL terminal system: Instruc-

tions for Operation. Yorktown Heights, N.Y.: IBM Corporation,
Thomas J. Watson Research Center, 1967. 27pp. plus many sample
problems.
FORTRAN McCracken, Daniel D. A Guide to FORTRAN IV Programming. New

York: John Wiley & Sons, Inc., 1965. 151pp. If there is a standard
introductory text, this is it.
MAD Organick, Elliot I. A MAD Primer. University of Houston, 1964.

250pp. (Available from Ulrich's Book Store, 549 E. University, Ann
Arbor, Michigan.)
Organick, Elliot I. The Michigan Algorithm Decoder, revised edi-

tion. Ann Arbor: University of Michigan Press, 1966. 130pp. This
is the official MAD programmer's guide. Superficially, MAD re-
sembles FORTRAN in many respects. However, it is much more
flexible and incorporates a facility for defining new operators and
redefining old ones. This makes it possible to expand or adapt the
language to special problems and applications (see SNOMAD below).
A new version of the language, MAD/I, and a MAD to PL/I transla-
tor written in SNOBOL4, is now being designed for use on third gen-
eration computers.
PL/I Weinberg, Gerald M. PL/I Programming Primer. New York: Mc-

Graw-Hill Book Co., 1966. 278pp.
Weiss, Eric. The PL/I Converter. New York: McGraw-Hill Book

Co., 1966. 113pp. The stated purpose of this book is to convert the
FORTRAN programmer to PL/I.
SNOBOL3 Farber, D. J., Griswold, R. E., and Polonsky, I. P., "The SNOBOL3
Programming Language". Bell System Technical Journal45, 6(July-
August 1966), 895-944. The basic technical description of SNOBOL3.
Farber, D.J., Griswold, R.E., and Polonsky, I.P., "SNOBOL, a

String Manipulating Language". Journal of the Association for Com-
puting Machinery 11, 1(January 1964), 21-30. More a programmer's
guide than a technical description.
Forte, Allen. SNOBOL Primer. Cambridge: Massachusetts In-

stitute of Technology Press, 1967. 107pp.
SNOBOL4 Griswold, R.E., Poage, J.F., and Polonsky, I. P., "Preliminary

Report on the SNOBOL Programming Language, II", revised edition,
20 March 1968. Bell Telephone Laboratories, Inc. Report #S4D4b.
Holmdel, New Jersey. 89pp.
SNOMAD Rosin, Robert F. "SNOMAD 2". Yale Computer Center Memo No.
14, New Haven, June 1967. Not a separate language, SNOMAD is a
set of defined operators and functions in the MAD language that allow
SNOBOL-like (i. e., string manipulation) operations within MAD pro-
grams. It is available at Yale and the University of Michigan. The
author of SNOMAD, R. F. Rosin, is a member of the Computer Science
Department at the Sate University of New York at Buffalo.


PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PDF

Загружено:

Авторское право:

Доступные форматы

Yale University Department of Music

Music Analysis and the Computer

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

In spite of the ever-increasing use and acceptance of modern

This article originally appeared in Computers and the Humani-

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

mine pitch-class distributions, there are as yet no standard

To acquaint himself with what can be done and some of what

A larger set of papers, more varied both in content and quality,

It is not my intention here to review the two publications as a

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

It is my feeling that, although the number of musicologists with

II. MUSICAL ANALYSIS BY COMPUTER: SOME GENERAL

Before delving into the particulars of the various articles, we

Eventually we will have automatic scanning devices to assist

1. An Encoding Language. Translation of the primary source

One of the problems that has plagued musical research in re-

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

guage, designed by Stefan Bauer-Mengelberg. *8 Intended for

It should be pointed out that although the Ford-Columbia lan-

2. Debugging and editing routines. Scanning the encoded data

To design and build a syntax analyzer is a nontrivial task, but

3. Analysis routines. These are determined by the internal

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

For those unfamiliar with the characteristics of these data

The parsing can be carried to further levels by deleting specific

List structures have obvious relevance to the formation of

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

Programming languages have been designed for each type of

III. SOME COMPUTER-AIDED PROJECTS IN MUSICAL

The novice who is looking for a lucid, non-technical introduc-

One of the lessons to be learned from Forte's research is that

It may be that theorists will take exception to the description

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

gested improvements for an otherwise model study would not

A nice companion article to Forte's general introduction is

The various kinds of information contained in the score

This method of stratifying and indexing the various attributes

Considering the relatively limited objectives of Lefkoff's anal-

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

his project. However, I do fail to see how introducing the con-

If I have reservations about Lefkoff's encoding principles and

Certainly the most ambitious undertakings in musical studies

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

trouble following their respective presentations, so it seems

In "A Multiple-Pass Transcription and a System for Music

1. A multiple-pass transcription code designated LMT (Linear

2. An elaborate 2-stage assembler program written in FAP,

Stage II proceeds as follows:

a. Intermediate table is read from tape, rhythm pass

The completed table is made up of 4 types of information, the

L Oxx ATTACK TIME VALUE

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

L+3 110 PITCH(b) INFORMATION

ATTACK TIMES are computed as floating-point numbers; since

3. Two external subroutines to be used in conjunction within-

a. an initialization routine to read the table from tape

Once this information is available to the calling program (written

Even more ambitious in scope than SAM is the system described

This content downloaded from 128.235.251.160 on Tue, 9 Dec 2014 18:59:00 PM

when there were few experienced programmers in the musico-

A MIR program consists of a series of instructions that may