From: AAAI Technical Report SS-93-01. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
REAL-TIME
MUSICAL ACCOMPANIMENT
BRIDGET BAIRD
7"heCenterfor Arts andTechnology
ConnecticutCollege
New London CT 06320 USA
Abstract. The artificially
intelligent computer performer is a software program that enables a computer to
accompany, in real-time, live performers. The computer is, in effect, a participating memberof a musical
ensemble. It interacts with the musicians by listening to them and it makes musical decisions based on what it
hears and what it Imowsabout music. The computer performer uses parallel processing to speed up its response
time. The implementation of the system is discussed, the tracking algorithm and the subsequent computer
response are described, and then ongoing and future work are outlined. Musical considerations which have
influenced the developmentof the system are also discussed.
1.
Background
Therelationship of musicto artificial intelligence and
cognitive science is complexand fascinating. Questions
about wheremusicresearch fits in these disciplines, what
approacheswill be mostfruitful, andwhatwill be the role
of the computerhavebeenstudied.
Artificial intelligence and music have a long
history of interaction. In 1980 two issues of the
ComputerMusicJournal were devoted exclusively to the
topic of AI and music. In 1981 Otto Laske published
Musicand Mind:An Artificial Intelligence Perspective
(Laske, 1981). In 1985 the ACM
devoted an issue
ACMComputingSurveys to computermusic, and in that
issue, in his article on "Researchin MusicandArtificial
Intelligence" Curtis Roadsadvocatesapplications of AI
methodologyand slrategies to music (Roads, 1885).
several of the AAAIsummermeetings there have been
workshops on AI and music. Because of the strong
influence of AI on computermusic research, parallel
processing and neural nets have recently played a
significant role in computer music research. The
ConnectionMachineat M1T(Vercoe, 1988) is just one
notable example. In 1989, two issues of the Computer
Music Journal
were devoted to neural nets and
connectionism.
Morerecently there has emergedthe field of
cognitive musicology, which "has as its goal the
modelingof musical intelligence in its manyforms"and
"...[whose] topics of primary concern... ate those of
understandingmusicaland musicologicalthought and its
link to musical action" (Laske, 1988). The role
cognitive science in this field and whetheror not music,
becauseit is based in perception, will employthe same
methodologies
as other branchesof cognitive science, is
being studied (Agmon,1990;, Laske, 1988). Also being
studied are questions about musical intelfigence and
whetherit is different from other intelligences and in
particular, its relationshipto linguistics. It is interesting
to note that in 1952John Myhill claimedthat "musical
thinking cannot be whollyaccountedfor in computational
terms"(Kugel,1990;, Myhill, 1952).
127
Thecomputerhas, of course, played an active role
in musicresearch. "For the in’st time in the history of
musical research, the computer program provided a
mediumfor formulating theories of musical activity,
whereasprior to its emergenceonly theories of musical
artifacts hadexisted" (Laske,1988). Computers
are being
used to test theories in cognitive musicology, to
improviseandcompose,as wonderfullyversatile computer
notationtools, andas instruments,tutors, andperformers.
It is this last role that wewishto examine
moreclosely.
For quite a few years computershavebeen used by
musicianseither to generatesoundsthat are impossibleto
produce on conventional instruments or even as
substitutes for conventional instruments. In these
capacities they havealso beenused in five performances.
But generallythe computerperformerhas beenlike a tape
deck, incapable of altering its performance,and thus
forcing the other performersto keeppace with it. It is
turned on at the beginning of the performance and
performsin exactly the samewayfor each performance.
"Anessential part of ’real’ musicis the live element,the
indefmablebut undeniableinteraction betweenplayers and
audiencewhichmakesmusicexciting" (Puckette, 1991).
Acomputerperformerthat acts like a tape decknot only
has no interaction with the other performers but also
prevents those live performersfrom any spontaneity or
interaction with each other or the audience. Whatis
neededis a moreintelligent computerperformer,capable
of interaction and capable of makingadjustments in
tempo,dynamics,andexpression.
There memanykinds of computerperformers, with
varying degrees of control exercised either directly or
indirectly by the other participants (Pressing, 1990). The
immediate
goalof this researchis to producean intelligent
computerperformerthat is capable of listening to the
other performers,and is able to react and interact in a
musical manner,but that is not directly controlled by
other performers.Themodelwouldbe a player in a siring
quartet, wholistens andreacts to other playersin matters
of dynamics and tempo, but whois not a leader in
controlling the performance,except within broad bounds
as specified by the score. Thecomputerperformerwould
playits part or parts froma scoreandalso has availableto
it the entire score for the piece. Sucha performerwould
be able to changeits tempoand dynamics,and evenff the
other performersmademistakes,it wouldbe able to guess
where they were and respond appropriately. Such a
performer would not have the ability to improvise.
Althoughimprovisationis an intriguing area of research,
it is not the focus here. Thekind of computerperformer
wehavedescribedcould be used both in live perftxmances
(a rock concert or a chamberensemble,for example)and
for training purposes(practicing for a concerto). The
ultimate goal of this research is to learn moreabout
musical cognition by producing such a computer
performer.Themainissues for this researchare to devise
a good tracking algorithm and then to determine an
appropriate musical ~.
Severalresearchershaveworkedon such a performer.
At Carnegie Mellon (Dannenberg, 1984; Bloch and
Dannenberg,1985) a computeraccompaniment
system was
developedthat followsa single live performer.In order to
track wherethe live performeris in the score, Blochand
Dannenberg
formulatedan algorithmthat uses pitches and
assigns costs to producethe best possible matchingwith
the score. At MIT(Vercoe, 1984; Vercoeand Puckette,
1985) researchers workedindependently on a similar
system. Unlike the Dannenbergsystem, this tracking
algorithm used both pitch and attack time to make
matches.Bothsystemsare limited to input from a single
live performer. The Carnegie Mellon system was
developedon IBMand Amigamicrocomputersand the MIT
system wasoriginally hosted on a VAX.
The Artificially Intelligent ComputerPerformer
(AICP) was developed on a Macintosh to implement
tracking algorithmthatuses
wholepatterns of notes in its
tracking algorithm(Baird et al., 1989a;1989b;to appear).
This tracking algorithm is described morefully below.
Bairdextendedthis workto considerinput fromseveral live
performersandusedparallel processingin order
to achieve
this (Baird, 1991).Baird, Blevinsand Zahlerreasonedthat
the wayto emulatehowlive performers track whenthey
are playingis to considermusicalpatternsas wholeentities
and not as isolated notes. Humansprocess notes as
musical motivesand not as discrete events in a vacuum.
Whenwe hear the opening notes of Beethoven’s Fifth
Symphony
Fig. I.
weconsiderit as a single musicalentity. TheBairdet al.
tracking algorithm morenearly reflects this situation.
Both the algorithm and the entire AICPare described in
moredetail in the rest of this paper.
2. Implementation
The artificially intelligent computerperformer is a
programwhichruns on ¯ Macintoshcomputer. All input
and output
isindigital
form. Althoughthere
aremany
128
intriguing and interesting problems associated with
recognizing pitch from analog sources, we decided to
consider only digital information, as specified by the
MIDIstandard. MIDIstands for Musical Instrument
Digital Interface, and is a universal standard for the
musical world. MIDIencodes pitch, volume and many
other musicalparameters.All synthesizers, for example,
comeequippedwith MIDIcapabilities. A variety of MIDI
instrumentsare available, and there are evenmicrophones
which translate voice and ambient sound into MIDI
information. Anydevice that will give MIDIsignals to
the Macintoshwill workwith the AICP.The Macintosh
receivesand sendssignals througha MIDIinterface, which
can be attached to either the modem
or printer port. The
Macintoshplays its computerpart(s) by sendingsignals
through the sameMIDIinterface. Several MIDIdevices
maybe connected to the computer, for either input or
output, or both. During a live performance, MIDI
information is transmitted to the Macthrough the
interface. Theinformationthat is neededfor the wacldng
algorithmis pitch and duration. Other MIDIinformation
about the score, suchas meterand tempo,is also used in
the program.
The Macintosh will process information from a
single live source, but in order to effectively handlemore
than one live performer, the Macmust be equippedwith
transputers. Transputersare 32-bit RISCmicroprocessors
which contain their ownmemoryand which are placed
inside the Macintosh to give it parallel processing
capabilities. The wansputerscommunicate
synchronously
with eachother
andwith the Mac;each wansputerhas four
input/output channels. Whena transputer sends a signal
it mustwait until the signal is receivedbeforecontinuing
on to the next instruction. Transputers achieve
parallelism both by having many of them connected
togetherand they also simulateparallelisminternally via
high speed switching. It is possible to set up multiple
processes to run simultaneouslyon a single transputer.
Transputersfit on boards that are placedin NuBus
slots;
communications amongtransputers are set up with
software commands.The Macintosh communicateswith
the fn’st transputer on each board. Since our boardseach
hold a maximum
of four transputers, we arranged the
transputersin a star configuration,withthe fwsttransputer
on each board communicatingboth with the Macintosh
and with the three other transputers. Althoughtransputers
on one board can communicate
with transputers on other
boards via a cable link, we did not choose to do this
because most of our communication is between the
Macintosh and the transputers and not between two
transputers. The transputer programs are written in
Logical SystemsC, and the Macintoshhost programis
wriuen in MPW
C. Whenthe program on the Macintosh
first begins, it sendsboot codeto the first transputerson
each boardandthenthe Macsends boot codefor the other
transputers via the first transputers. All communication
betweenthe Macand the transputers passes through the
first
transputers
oneachboard.
Whenwefirst started workingwith the transputers
weused a commerciallyavailable interface (Express)
makecommunicationeasier. Becauseof the relatively
large overhead of this system, and because real-time
processing is a crucial componentin this system, we
eventually scrappedthat interface andhavebeenworking
out our own communications. This has enormously
speeded up the communication
time but also enormously
added to our programming
time. Wehave established our
own broadcast and message passing system, loosely
modeledon that of Express. It should be noted that
debuggingwith transputers is a moretedious processthan
on a conventional machinebecause there is no direct
output
device.
After the program
starts up, the user can specifythe
musical score to be loaded. These scores must be in
standard MIDIformat (most musical notation programs
will produce this format). Each part in the score
correspondsto a single MIDIchannel. Thepresent limit
is eight channels(purely for convenienceandcost). Once
the score is loaded,the user has choicesabouteachof the
channels (parts). A channelmaybe designatedas a live
channel, a channelto be played by the computer,a file
channel, or turned off. File channelmeansthat the part
will be played from a file. This file maybe either one
producedin the MIDIformat, or it maybe a file which
has beensavedfroma previousperformance
and is in our
ownformat. Performancescan be saved for future use or
can be specially construed. Since we are considering
multiple live inputs andsince our playing abilities are
limited by two hands and not muchexpertise, this is an
essential feature. It also allowsfor exact replications of
performances,whichassists in evaluation of the program
and in debugging.The user has additional options: to
changethe original tempoof the score, to choosea MIDI
port, andto turn off the tranaputers.Theuser is also able
to select the type of performance:
a live performance
with
combinationsof live and f’fle instruments, a computer
performance
with the computerplayingany or all parts of
thescore,or a replayof the last live performance.
Beforethe performancebegins, the programdoes a
pre-performancereading of the score, muchthe waylive
musicians might do. Tempoand beat information are
noted. Then each live performer (or MIDIchannel)
assigned to one or moretranaputers. Thesetranaputers
receive the score for that MIDIchannel and during the
performance are provided with incoming musical data
aboutthat player. At least one transputer keepsa window
into the score positionedat whatit believesis the correct
location of that performer.Thepreviouslocation and the
start of newnotes governwherethis window
is placedin
the score. If goodmatchesare not obtained, then the
windowmovesforwardas newnotes are played. If there
are enoughIranaputers,an additionaltransputeris assigned
to a single channel,but this tranaputercontinuallychecks
the beginningof the score. It assumesthat the player is
starting over from the beginning of the piece. Each
transputeruses the trackingalgorithmto performa pattern
matchof the incominginformationto the score for that
channel,and then sends backto the Macintoshan estimate
of the location in the score of that live performer.The
Macintoshreconciles the information from (possibly)
manytransputers and decides on an overall response.
Based on its conclusions it plays its owncomputer
part(s). Since the computermust emulate a live
performer,speed is of the essence. Evaluationsmustbe
129
madequickly so that acceptable real-time accompaniment
is feasible. Duringa performancethe AICPis faced with
essentially two tasks: to determinethe location in the
scoreof each of the live performersand to determinethe
tempoand location at whichit itself should play. This
involves not only reconciling possibly conflicting
informationfromthe various live channelsin a musically
informedmanner,but respondingwith its ownpart in a
musicallyacceptable manner.
3. Tracking
Algorithm
This section describes the tracking algorithm of
Bairdet al. Thefirst step in determining
the correct score
position is to treat each live performerseparately. The
incoming
data for a single live performeris matched
to the
scorefor that instrument.If there are tranaputersthenthis
matchingtakes place on them; otherwise the Macintosh
performs the tracking algorithm for a single live
performer. This tracking algorithm takes place as
follows. The most recently heard notes constitute a
performancepattern. This performancepattern is matched
to several score patterns. Thepossiblescore patterns are
determinedby looking througha "window"
into the score.
Thecenter of this window
is placedat the best guessas to
the currentcorrect score position. Scorepatternsare taken
within this window.Thesize of the windowand the size
of the patterns (both performerand score) are governed
processingtime, althoughpatterns are not allowedto be
too large becauseof musical considerations. A single
performancepattern is matchedto each of manypossible
score patterns and a cost is assignedto each match.The
minimum
cost from all of these is picked, and both the
cost and the location in the score of that best matchis
conveyedto the Macintosh.
Thecost of a matchof a performancepattern to a
score pattern is based on both duration and pitch
informationfor all the notes in the performance
pattern,
with the mostrecently heardnotes carryinggreater weight.
Pitch mismatchesincur a relatively greater cost than
duration ones. In fact, since musicians maybe rather
inexact about endingtimesof notes, someof these "gaps"
are smoothed
over. Rests constitute a type of "note" and,
with someslight modifications,are treated as such. One
musical problem is to determine whena performer is
intentionally playinga rest andwhenthere is merelya gap
in the performance. In absolute time it is perfectly
possiblefor there to be a rest in the score that is longer
than a performer’s pause betweentwo successive notes.
Thealgorithmtakes into accountthis kind of scenario. In
fact, there are four types of individual note matchesthat
are considered.Threeof these matchesanticipate the kinds
of mistakes that musiciansare likely to makeduring a
performance.
The furst kind of note matchis a verbatim match.
Onenote in the performance
is matchedto onenote in the
score (either of the notes could be a rest). A cost
assignedfor incorrect pitch; the greater the differencein
pitchesthe greater the cost, modulo
the octaves.. Acost is
also assignedfor differences in duration. Aslong as two
successive performancenotes do not have a rest, the
algorithmassumesthat the endof the first note is at the
beginningof rite next one, so the gaps betweennotes are
smoothedover.
The second kind of note match, an amalgamated
match, occurs whenthe perfo~nerplays a wrongnote and
then immediately
corrects it to the fight note. Twoof the
performer’snotes are matchedto one of the score notes.
Thepitch of the performer’ssecondnote is comparedto
the pitch of the score’s note, andthe samof the durations
of the performer’stwonotes is compared
to the durationof
the score note. This exampleis illustrated in Figure2.
~0re
Live
Perlormer
Fig. 4.
Live
Performer
Fig. 2.
Thethird type of match, the held through, is when
two notes in the score are matchedto a single performance
note. Theperformerhas missed playing one note and has
instead held the previous note through the time of the
secondnote (see Figure3). Thepitch of the performer’s
note is compared
to the pitch of the first notein the score
andthe durationof the performer’snote is compared
to the
sum of the durations of the two score notes.
Score
Live
Performer
Fig. 3.
Thelast type of match, the rest, occurs whenthe
performerreleases a noteearly, probablyin anticipationof
the next note or passage(see Figure 4). Thegap that
caused by the early release might be long enough to
count, in the computer’s view, as a resL It is not
desirable to shorten the length of time the computer
considersa rest becausethere mayin fact be places in the
score wherethis length of time shouldcount as a rest. On
the other hand, treating this situation as a rest in some
cases would cause undue cost to be assigned in the
trackingalgorithm.Instead, in this situation the duration
of the performer’spauseis addedto the previousnote and
this unit is compared
to onenote in the score.
130
In order to calculate the entire cost for a matchof a
performance
pattern to a score pattern, the last notes(most
recently heard)are treated t-u-st. For each note the four
types of matches outlined above are considered and
possible costs computed.For all but the verbatimmatch,
a small penalty is addedto the cost. Thealgorithmthen
considersall four possibilities for all of the notesin the
pattern, andaddsthese to the total cost. Thealgorithmis
performedrecursively. Thecomputerhas an upper bound
on acceptablecosts so that obviouslyunprofitable paths
are cut off. At the end of one pattern matchthere is a
total least cost. This processis repeated for each score
pattern. For each successive score pattern, the
accumulatingcost is comparedwith the best cost so far,
so that dead ends are eliminated. Finally, the overall
minimal
cost is selectedfromall the score patterns.
This part of the program is computationally
intensive and since respondingin real-time is a major
consideration,the parallel processinghelps this part of the
program. Throughexperimentation, it was determined
that if the tracking algorithm takes more than
approximately5/60 of a second, the degradationin the
computer’sresponseis too great. This constraint governs
the size of the windowand the size of the patterns. The
size of the patterns is also restricted by musical
considerations. Whenthe Macintoshis running without
transputers,this restriction on processingtime effectively
limits the performanceto one or two performers and
limits the window
size to about5 notes wide.
Oncethe best cost has been determined, this also
givesa best beat as specifiedby the location of that score
pattern. Locationin the score is calculate by the total
numberof beats fromthe beginningof the piece. These
two pieces of information, beat and cost, are
communicatedto the Macintosh. The Macintoshstores
this informationandalso the time (on the computerclock)
whenthe informationarrived.
4.
Computer Performer Response
Oncethe programreceives beat information froma live
channelandalso an estimateas to the reliability of that
information(cost of the trackingalgorithm)it mustdecide
on its response.If there is morethan oneperformer,then
conflicting locations maybe indicated by the different
performersand then the AICPmust, in effect, becomea
conductor,and determinea "true" location and a "true"
tempo.
In these considerations, the issues of time and
tempo are extremely importanL The computer has its
owninternal clock, whichis keepingan absolute time;
each transputer keeps an absolute time also, although
becausetheir units are different fromthe Macintosh’sand
becauseany communication
betweenthe computerand the
transputers takes an (albeiO small amountof time, there
are minor inconsistencies. Tempois not an absolute.
There is the tempoof the piece, there is the tempoat
whichthe computer
believesthe piece is beingplayed,i.e.
a conductor’s tempo,there are the temposat whichthe
live performersare playingand then there is the tempoat
whichthe computermight be playing (slowing downor
speedingup) in order to catch the rest of the players. The
two absolutes in the piece are the internal clock of the
Macintoshand the beats in the score. Everythingelse is
relative.
In order to decideon onelocation in the score, all
of the beat andcost information,andthe computertime at
whichit wasreceivedfromthe various performers,are put
into an array. Alinear least squaresfit of beat vs. timeis
performedto determinethe tempoof the piece. This least
squaresfit is weightedaccordingto the mostrecently heard
informationandalso accordingto the reliability or cost of
each piece of information. This meansthat movinglines
will have a greater say in determiningthe tempo,which
generally is consistent with musical interpretation.
Movingparts often have the melodyand thus should take
the lead in determining tempo, although movinglines
mayalso denotesecondaryinstrumentsandit is debatable
whetherthey should be allowedto keepthe beat. It is
also possible to weightthe least squaresfit accordingto
the instrument.For example,in a string quartet the first
violin might be assigned a greater weight and thus be
given moresay in determiningthe tempo.
Thelinear least squaresfit will give the computer
not only an indication about the correct current beat but
will also give the current tempo,whichcan be foundfzom
the slope of the line. Nowthe computermust decide on
the correct response. At this point the computerbelieves
it knowsthe correct beat and the current tempo.Chances
are the computer
is not in the exactcorrect locationin the
scoreandis not playingat the current tempo.
One possible response for the computer is to
simplymoveto the correct location and to start playing
the correct tempo. Themainproblemwith this approach
is that it is not in conformancewith howhumansmake
music. There maybe situations in which the computer
shouldshift its location in the score, but only whenit is
very far fromthe correct location. Andin that situation,
the computermighthaveto wait before shifting if it has
only just beguna note. In effect, the computermustbe
slowed downto humanspeed. If the computerholds a
note for an extremelyshort period of time, the result is
jarring and unmusical. But in most situations the
computershould not jumpto another location in the score
but shouldslowdownor speedup to catch the performers.
Howmuchit should adjust its tempoin order to catch
themdependson several factors.
Thefirst factor is a musicaloneandis governedby
musicalexperimentation.Whatisneededis to determine
an interval over whichthe computercatches the live
131
performers.It is a parameterthat is set to betweenone
and two seconds. Less than one secondsoundsartificial,
and moreappears to be inefficient. Thesecondfactor is
governedby the kind of piece that is being played. In a
Bach chorale, the tempo should never be unduly fast,
whereas in a vivace movement,there is more leeway
about speed. Thusthere is an upper limit established.
There seems to be more latitude about a lower limit,
however. Anincredibly slow tempoessentially amounts
to holdingnotes, anddoes not soundterribly out of place
even in fast movements.Theseupper and lower ~mits are
set by the pre-performancescore consultation and are
governedby the meterandtempoof the piece. In fact, as
pieces are read in, several parameters,suchas these, are
set. But even if a tempois allowed by the upper and
lower bounds,it maybe inappropriate becausethe change
is too abrupt. Thusthe previous tempoalso sets limits
on the ensuingone.
Although tempo is perhaps the most important
consideration,there are other factors to be noted. Asthe
programplays a performanceit also checks the dynamics
of the other players. Incomingdata is checkedagainst the
scoreandif there are large differencesin dynamics
then the
AICPmodifies its response by playing softer or louder
also.
It is possible that the incominginformation is
deemedtoo unreliable to act upon, i.e. the costs are
unacceptablyhigh. Thenthe response of the AICPis to
continueplaying, while gradually reverting to the tempo
specified in the score. In an earlier version of the AICP,
if the computerdetermined that the live player was
hopelesslylost (in its view)then it wouldstop playing
for a short while and then jumpahead to a place in the
musicjust after a tonic cadence(as found by the preperformance
score consultation). It wouldalso play quite
loudly. This wouldcorrespondto giving a cue to start
playing at the beginningof a newsection. This kind of
jumpwouldonly workin classical western tonal music,
for only in those pieces could the computeridentify the
key of the piece and then also be able to identify the
cadences.
5.
Ongoing
and Future
Work
At present the author is in the midst of workingon the
reconciliation aspect of this work. The system works
extremelywell whenthere is a single live performer.It is
difficult to throw off the computer, even whenmany
mistakesare made,and the computerbeautifully follows
the tempoof the live performer. Whenthere are several
live performers, the computertracks them reasonably
well, as long as they are not themselveswayout of step
with each other, whichis about whatshould be expected.
Muchmore experimentation needs to be done to "tune"
the weightsand parametersthat are used in the multiple
live input case. There is a difficulty in obtaining
appropriate test data. If the live performers’parts are
given by files, they tend to haveno affect on eachother,
whichis not the case for a true live performance.But in
executinglive performanceson several instrumentsthere
is a great tendencyfor the performersto havea great affect
on each other and all play at the sametempo, in which
case the system does quite well. The best data comes
from two experienced players, whenone of them is asked
to lead and change tempo, and the other follows suit,
albeit slowly. Perhaps the lesson here is that in most
ensembles there will tend to be one tempo, and the
computer performer need not worry too much about
reconciling
wildly conflicting information.
At present
parallel
processing
is usedin a very
straightforward manner, mainly to give the system greater
speed. Different processors correspond to different
performers, which begins to emulate the parallel nature of
humancognition, but as more is known about musical
cognition, this whole area could open up muchmore.
A very promising domainfor further research is to
examinethe tracking algorithm. It wouldbe preferable if
the algorithm not only used patterns of notes, but actually
used more musical patterns of notes. This would more
closely emulate what humansdo in a musical ensemble.
This gets into the fascinating and difficult area of
recognizing what constitutes a musical pattern and also
lJossibly recognizing whenpatterns are essentially the
same (Kendall, 1986; Hulse et al., 1992). At the very
least, the system should be modified so that musical
patterns do not cross obvious musical boundaries, such as
ends of phrases or sections. There is muchinteresting and
fruitful research still to be accomplished.
Acknowledgments:The author would like to thank the
KnowledgeModels and Cognitive Systems program of NSF
for supporting this rese4~ch under grant IRI-9010793.She
also thanks her early collaborators, DonaldBlevins and Noel
Zahler, for their continuedinput.
References
Agrnon,E.: 1990, MusicTheoryas Cognitive Science: Some
Conceptual and Methodological Issues, Music
Perception, 7, 3, pp. 285-308.
Baird. B.: 1991, The artificially intelligent computer
performerand parallel proce~sin8, /n Proceedingsof the
1991International
ComputerMusic Conference,
International
Computer Music Association, San
Francisco, pp. 340-343.
Baird, B., Blevins, D. and Zalder, N.: 1989a,Theartificially
intelligent computerperformer, bs Proceedingsof The
Arts and TechnologyH, Connecticut College Press, New
London,Connecticut, pp. 16-23.
Baird, B., Blevim,D. and Zahler, N.: 1989b,Theartificially
intelligent computerperformeron the Macintosh11 and a
pattern matching algorithm for real-time interactive
performance,
inProceedings
ofthe1989International
ComputerMusic Conference, International Computer
MusicAssociation, San Francisco, pp. 13-16.
Baird" B. , Blevins, D. and Zalder, N.: to appear, Artificial
Intelligence and Music: Implementingan Interactive
ComputerPerformer, ComputerMusic Journal..
Bloch, L J. and Dannenberg, R.B.: 1985, Real-time
computer accompanimentof keyboard performance, in
Proceedings
of the1985Internat~al
Computer
Music
Conference,
International ComputerMusic
Associa~.ion,
San Francisco, pp. 279-289.
Dmmenberg,
R. B.: 1984, An on-line algori~ for real-time
accompaniment, in Proceedings of the 1984
132
International
ComputerMusicConference,
hteraational
ComputerMusic Association, San Francisco, pp. 193198.
Hulse, S., Takeuchi, A. and Braates~ R.: 1992, Perceptual
Invariances in the ComparativePsychology of Music,
MusicPerception, 10, 2, pp. 151-184.
KendallR.A.: 1986, Therole of acoustic signal partitions in
listener categorization of musical phrases, Music
Perception, 4, 2, pp.185-214.
Kugel, P.: 1990, Myhill’s Thesis: There’s More than
Computing in Musical Thinking, Computer Music
Journa/, 14, 3, pp. 12-25.
Laske, O.: 1981, Music and Mind:An artificial intelligence
perspective,
Computer Music Association,
San
Francisco.
Luke, O.: 1988, Introduction to Cognitive Musicology,
ComputerMusicJournal, 12, I, pp. 43-57.
Myhill, J.: 1952" SomePhilosophical Implications of
MathematicalLogic: Three Classes
of Ideas, Reviewof
Metaphysics, 6, 2, pp. 165-198.
Pressing, J.: 1990, Cybernetic Issues in Interactive
Performance Systems, ComputerMusic Journal, 14, 1,
pp. 12-25.
Puckette, M.: 1991, Something Digital, ComputerMusic
Journal, 15. 4, pp. 65-69.
Roads, C.: 1985, Research in music and artificial
intelligence, ACM
ComputingSurveys, 17, 2, pp. 163190.
Vercoe, B.: 1984, The synthetic performer in the context of
live performance, in Proceedings of the 1984
International Music Conference, International Computer
MusicAssociation, San Francisco, pp. 199-200.
Vercoe, B. and Puckeue, M.: 1985, Synthetic rehearsal:
Training the synthetic performer, in Proceedingsof the
1985 International
Computer Music Conference,
International
Computer Music Association, San
Francisco, pp. 275-278.
Vercoe, B.: 1988, Hearing polyphonic music with the
connection machine, in Proceedings of the First
Workshop on Artificial
Intelligence and Music,
Minneapolis/St. Paul pp. 183-194.