Andreas Stefik,* Melissa Stefik,* and
Mark Curtiss
*School of Electrical Engineering and Computer
Science
Washington State University
P.O. Box 642752
Pullman, Washington 99164 USA
16265 SW Blanton Street
Beaverton, Oregon 97007 USA
{stefika, harrismel, markcurtiss}@gmail.com
Since the 1950s, scientists have attempted to codify
human language and to write automatic translators
from one language to another (Locke and Booth
1955). This translation problem is strikingly diffi-
cult, caused not only by syntax, but by the meaning
or semantics of the languages themselves. In this ar-
ticle, we present a translation problem of a different
nature: the translation between musical languages.
A musical language comprises both the symbols
that represent sound or music and the underlying
meaning of those symbols. Musical languages show
striking similarities to natural languages. Just as in
natural language, similar symbols can imply the
same, or similar, underlying meanings. Musical lan-
guages present different levels of information, rang-
ing from very exacting to rough approximations of
what the performer should do. Trying to reconcile
approximations with the exact is musically analo-
gous to the colloquial phrase lost in translation.
A musical language translator may be beneficial
in studying historical music, unusually notated mu-
sic, or for simplifying the notation of a complicated
score. Just as there are a variety of spoken languages,
there is a vast and growing number of musical lan-
guages. It is unreasonable to expect composers or
performers to understand all musical languages.
Translations may require expertise in two or more
notation systems, and translating musical lan-
guages by handeven with the required knowl-
edgeis both tedious and time-consuming.
Thus, we present Ammmp, a general-purpose
musical language translator and music-notation
editor. Ammmp has several musical languages and
translators implemented. Currently, we have imple-
mented Ben Johnstons microtonal notation, a form
of microtonal performance notation, standard non-
Computer Music Journal, 31:4, pp. 3346, Winter 2007
2007 Massachusetts Institute of Technology.
An Automatic Translator
for Semantically Encoded
Musical Languages
microtonal Western notation, and a form of chro-
matic staff notation invented by Grace Frix. All of
these musical languages can be automatically trans-
lated to any others in Ammmp.
As we will demonstrate, not all translators are
created equal. Some translators require an alteration
of a musical languages semantics, others require
changes to the graphics, and still others require both.
We see Ammmp as a system that translates musical
languages in the general sense, and present a frame-
work for doing so. We chose microtonal notations
to demonstrate languages that are extremely diffi-
cult to translate, and we chose a chromatic staff and
standard Western notation as examples of relatively
straightforward, non-microtonal, translations.
Since 2002, we have been using Ammmp technol-
ogy, or pieces of it, to provide the Kepler Quartet
with synthesized recordings of several of Ben John-
stons string quartets (Johnston 2006). This technol-
ogy, as it evolved, was an invaluable tool for the
quartet in hearing and understanding Ben John-
stons musical language.
In the course of this article, we first present re-
lated work and the Ammmp music-notation frame-
work, including the translation framework. Next,
we discuss both the basic concepts in microtonal
music theory and several music notations for which
we present translators. Lastly, we discuss our meth-
ods for automatic musical language translation, fo-
cusing on the most difficult translation, back and
forth from Johnston to performance notation.
Background
Designing and implementing a music-notation edi-
tor is a serious undertaking. Algorithms as seem-
ingly simple as spacing a line of music have a rich
history (Gourlay 1987; Haken and Blostein 1995;
Stefik et al. 33
Bellini and Nesi 2004), and determining a proper
design for the system is equally challenging (Bran-
dorff, Lindholm, and Christensen 2005). In this sec-
tion, we present work relevant to translating
between languages, both musical and otherwise.
Brown, in a 1958 talk at Georgetown University,
said, I must begin by admitting, as is scarcely nec-
essary, that I am at least several months away from
being able to feed a new piece of French text into a
computer and have an English translation come out
at the other end (Brown 1958). The translation
problem at this early stage was far from solved.
What is enlightening about this text, however, is
that Brown said he was several months away in
1958, perhaps showing how deceptively difficult
this kind of work can be.
One element of particular difficulty in language
translation is the meaning of words, or semantics.
Early work considered only the syntax of language,
which was soon shown to be inadequate for general-
purpose translation. This led to the infamous trans-
lation of the spirit is willing but the flesh is weak.
This sentence was translated, or so the story goes,
into Russian and back into English. Upon transla-
tion back into English, the sentence became, The
wine is agreeable but the meat has spoiled. Al-
though there are many conflicting versions of this
story, the point is that the meaning of the sentence
was not preserved. For an excellent review of lan-
guage, including its myriad of complexities and dif-
ficulties see Whitney (1998).
In our musical translations, we also had to con-
sider the implications of syntax and semantics. For
example, in early versions of our music-translation
system, we discovered we could obtain mathemati-
cally accurate answers, but that occasionally the an-
swers would involve notes with nearly 40 or 50
microtonal accidentals. In other words, our issue
was the opposite of the problem natural language
researchers had. Our initial results technically pre-
served the meaning of an individual notationse-
manticsbut the syntax was extremely complex.
Semantic maps were used by Raman and Alwar
(1990) to solve translation problems. In that work,
host languages, like English, are translated into a
semantic map, and then a generator is used to
34
translate this semantic map into another language.
We did not use a semantic-map-based approach, as
some musical languages are mere approximations of
others, making a baseline map hard to envision for
our purposes.
Hajic, Hric, and Kubon show a translation system
for two very similar languages, Czech and Slovac.
They propose that, for very similar languages, a
simple word-to-word translation may suffice (Hajic,
Hric, and Kubon 2000). On a 10,000-word match
sample, they showed results within about 90 per-
cent accuracy. The musical languages we chose
were not similar, but Ammmp does translate on a
symbol-by-symbol basis.
Because Ammmp is a music-notation editor, in
addition to a musical language translator, one par-
ticularly difficult problem was music formatting. A
variety of formatting algorithms exist (e.g., Blostein
and Haken 1991; Haken and Blostein 1995; Bellini
and Nesi 2004), but a treasure trove of information
on music formatting was created by Gourlay and
his colleagues at The Ohio State University
(Gourlay 1987; Gourlay et al. 1987; Hegazy and
Gourlay 1987; Parrish and Gourlay 1987). These
technical reports are an invaluable resource for any
designer of a music-notation editor.
Some of the work in the present article references
microtonal music and microtonal musical lan-
guages. Several good resources explain microtonal
theory in more depth than is possible in this article
(Chalmers 1992; Doty 1994). For more information
specifically related to Ben Johnstons notation sys-
tem, see Johnston (1964) and Fonville (1991). Espe-
cially important in Fonvilles work is a list of
Johnstons accidentals and their meaning. We ex-
pand Fonvilles work here by showing Johnstons
notation up to the 61st partial, whereas Fonville
showed only up to the 31st.
We translate among four different musical lan-
guages in this work: Ben Johnstons, performance
notation, standard Western notation, and a chro-
matic staff. Ben Johnstons graphical notation looks
very similar to common Western notation, but it
assumes the score is in just intonation and adds sev-
eral microtonal accidentals to account for this. Al-
though his notation has evolved over his lifetime,
Computer Music Journal
Figure 1. Results of the
translation among all four
musical languages we im-
plemented. Johnston nota-
tion (top) uses numbers
and symbols to indicate
microtonal pitch varia-
tions. In performance nota-
tion (second from the top),
the numbers indicate cents
deviations from equal tem-
pered pitches. Standard
Western notation (second
from bottom) and a chro-
matic staff notation (bot-
tom) are close
equal-tempered approxi-
mations to the Johnston
and performance notation.
All of these translations
were accomplished auto-
matically by Ammmp.

we implement his current system in Ammmp. Per-
formance notation is any microtonal notation that
displays cents values next to an equal tempered
pitch. Our particular variation displays these cents
values as accidentals near the note, but it is com-
mon to see them above a note.
Standard Western staff notation probably needs
no introduction, but the chromatic staff does. The
chromatic staff (of which we present a version by
Grace Frix) is similar to standard Western notation,
except that each of the twelve notes of the chro-
matic scale has its own line or space. The point of
a notation like this is that it removes the need
for key signatures, making all keys graphically
equal. To motivate the translation problems pre-
sented in this article, Figure 1 presents a translation
between all four of the musical languages we chose.
Lastly, our goal in creating a music-language
translator arose owing to the vast complexity of
musical languages, especially as they have grown in
the 20th and 21st centuries. Although a number of
sources exist, for a good overview of a number of
20th-century music notations, see Stone 1980.
Microtonal notations, like Harry Partchs (1974),
are more varied in number and style than their non-
microtonal counterparts.
Translation Framework
The design goal of the Ammmp project is to create a
robust music-notation editor with the ability to
translate between alternative musical languages,
both graphically and mathematically. This includes
changing historical musical languages into their
modern equivalent and vice-versa. Creating a
framework for musical languages such as this re-
quired us to write a custom sound-synthesis engine,
a graphics engine, a translation framework, and a
large array of GUI components. Because there has
been a recent interest in the design of these systems
(Brandorff, Lindholm, and Christensen 2005), this
section of the article offers an alternative approach
for the design of modern music-notation frame-
works. Figure 2 shows the primary components in
the Ammmp architecture.

Stefik et al. 35
Figure 2. Primary compo- Figure 3. Screenshot of the
nents in the Ammmp Ammmp interface.
architecture. We imple-
mented our architecture
in Java.

Figure 2

Figure 3

The first component in Ammmp is the Main-
Frame, which is the primary GUI component. Al-
though Ammmp is not a fully featured commercial
music-notation editor like Finale, Sibelius, or Lime
(Blostein and Haken 1991; Haken and Blostein
1995), the user interface is sufficiently featured for
common music-notation operations. As can be seen
in Figure 3, users can adjust time signatures, clefs,
notes, accidentals, and other related items using a
what you see is what you get interface.

36 Computer Music Journal

 Because Ammmp is concerned with musical lan-
guages, we include a component called the Nota-
tionManager, which knows what languages can be
translated. For example, this component recognizes
that a Johnston-to-performance translator is avail-
able on the system.
The graphical representation of the music in
Ammmp is created in a MusicPanel component.
The MusicPanel contains several important class
hierarchies that control the primary functionality of
the program, namely the AbstractScorePlayer, the
AbstractScoreIO, the AbstractHitDetector, the Ab-
stractController, and the Score. Each component in
this hierarchy of classes is music-language neutral,
that is, other Ammmp components usually go un-
changed when we translate between arbitrary musi-
cal languages.
The AbstractScorePlayer object converts the
Score object into sound. MIDI is a common tool for
notating music in an editor like Finale or Sibelius.
To implement microtonal music, however, MIDI
support is incomplete. Specifically, the only method
available for creating microtonal music with MIDI
is to use pitch bends. One pitch bend is allowed per
channel. Consider an example where some MIDI
channel had two notes playing simultaneously and
a pitch-bend message was sent to that channel. This
pitch bend message would cause both notes to
change pitch. Because only 16 MIDI channels are
typically available, only 16 unique microtonal
pitches can be performed simultaneously. To over-
come the limitations of MIDI, we built a custom
sound-synthesis engine into Ammmp.
The AbstractScoreIO hierarchy allows various
types of file-saving to occur. In our case, because
we focus on the semantics of musical languages
which is typically not encoded into standard music
file formatswe decided to use the Java languages
default file-saving mechanism: serialization. It
would be advantageous to integrate Ammmp files
into the MusicXML standard (Good 2001), but lan-
guage translation, semantics, and microtones signif-
icantly complicate this process.
The next two primary components in Ammmp
are the AbstractHitDetector and the AbstractCon-
troller. The AbstractHitDetector determines the ob-
ject with which the user is interacting, and the
AbstractController determines what action to take
for a component when it is hit.
Score objects are the primary representation of
the music itself. The Score contains what might be
expected: measures, notes, clefs, time signatures,
and musical languages. Score objects store an Ab-
stractNotation object, which is an abstraction of a
musical language. In computer terms, we use what
is called the strategy design pattern to accomplish
this (Gamma et al. 1995). This technique allows us
to swap out how a given musical language is repre-
sented, graphically and mathematically, without al-
tering the way our graphics library interacts with
the graphics systems.
Last, we have the AbstractPositioner and the Ab-
stractNotationConverters. The AbstractPositioner
moves notes, measures, and other elements on the
screen and the AbstractNotationConverters trans-
late between two given AbstractNotation objects.
Review of Microtonal Music Theory
While Ammmp attempts to encode the semantics
of musical languages, any that involve microtones
can be very difficult to automatically translate,
which makes them good examples. Microtonal the-
ory is, however, relatively complex, and as such, we
offer a short review section here.
Microtonal theory is largely broken into two cate-
gories, the tempered tunings and the just tunings.
Just tunings use integer ratios to represent pitches,
whereas pitches in a tempered tuning deviate from
those ratios. The most common form of tempera-
ment is equal temperament, and in particular,
twelve-tone equal temperament, or 12-TET. (This is
the tuning used on the modern piano.) In 12-TET,
notes on the scale are derived logarithmically, the
frequency relationship being 2i/12 for any note, where
i is the scale step desired. In equal temperament
(and in just intonation as well), the fundamental fre-
quency of notes are relative to a base frequency,
commonly referred to as the 1/1 (Partch 1974). The
1/1 literally means a frequency with which all other
notes are compared. Generalizing, if z-tone equal
temperament is desired, we have m = x 2y/z, where
z is the number of divisions of the octave, m is the
Stefik et al. 37
Figure 4. A 3-limit lattice Figure 5. A 5-limit lattice Figure 6. A 5-limit lattice
in just intonation. Al- in just intonation. of notes in Ben Johnstons
though often presented on musical language.
a horizontal axis, the di-
rection is arbitrary, and we
are following Johnstons
usage.

Figure 5
final frequency, x is a base frequency, and y is a
scale step. For a thorough overview of tempera-
ments, see Barbour (1951) and Jorgensen (1991).
In comparison to the mathematical structure of
equal temperament, just intonation uses ratios to
represent pitches. Typical just-intonation systems
are broken into limits. A 5-limit just intonation
system uses ratios in which the largest possible
prime number in any numerator or denominator
factorization is 5. Likewise, the ratios used in an
n-limit system are limited to prime factors no larger
than n. For our theoretical purposes, it is conven-
ient to consider all just intonation pitches as pitch
classes, existing only between the unison (1/1) and
the octave (2/1).
A common way to visualize a just-intonation
system is by using a lattice (Johnston 1976/1977;
Fokker 1949). A lattice is a graph in which each Figure 6
node represents a just-intonation pitch, and each
edge represents a ratio relationship between two
pitches. In Figure 4, for example, the interval be- Musical languages like Ben Johnstons are a one-
tween 1/1 and 3/2 is 3/2. Lattices often have a cen- to-one mapping from a lattice to notes on the staff.
ter node on the graph, typically 1/1. Figure 6 shows a 5-limit lattice of notes in Ben John-
As an example, consider the 3-limit lattice pre- stons musical language.
sented in Figure 4. Because this lattice is 3-limit, As an example of how pitches are calculated in
we can say that the dimensionality of the lattice is this system, consider 15/8 in Figure 5. To calculate
one, a line. Note that a one-dimensional lattice, in this pitch, we go to the east and then the north, or
this case, is equivalent to a Pythagorean tuning. alternatively, the north and then the east. Regard-
Figure 5 expands this lattice to 5-limit, creating a less of the steps, the calculation is one step in the
2-dimensional lattice. positive direction for a 3-limit system and one step

38 Computer Music Journal

in the positive direction for the 5-limit system. This
implies our final ratio is 3151, although this gives us
the value 15. We then must octave-reduce the num-
ber to fall within one octavei.e., take a value be-
tween 1/1 and 2/1and thus we divide the number
by 8. Similarly, for 64/45 we would have a note re-
duced from 32 52, because, in this case, we are
going in the negative direction for both axes.
Note that in this system as described, notes are
perfect fifths apart in the northsouth dimension.
However, because note names repeat, and the ratios
are different for these notes, we designate the differ-
ence with a or + symbol. This extra symbol indi-
cates a syntonic comma, or the ratio 81/80. The rule
here is that a perfect fifth above any variant of D,
like D-flat (D !), D-sharp (D#), or D !+, in the lattice
adds a syntonic comma, or likewise below an A.
Similarly, a major third above any D also adds a syn-
tonic comma. Interestingly, this language preserves
just intonation relationships via extra accidentals.
To calculate the note name for the ratio 15/8, we
go to the right from the 1/1, or C, to the note E, add-
ing a major third. Next, we go north from E, adding
a perfect fifth. This gives us the final note of B.
It is often convenient to represent a lattice mathe-
matically. To do this, we first define a function r(x),
where x is either a real number or a ratio that can
reduce a particular note to a pitch class within a 1/1
and a 2/1. Thus, if we have some set of primes in
our lattice p0 . . . pn1 and a set of integer exponents
for each prime m0 . . . mn1, then to determine the
pitch-class fundamental frequency of a note, we
compute
n1
note = r pimi (1)
i =0
Equation 1 shows how to calculate fundamental fre-
quencies and illustrates that we ignore octaves in
our calculations. As a succinct representation of a
lattice, we use a vector. Thus, the note G could be
represented as v = {1}, where the first position in the
vector is the prime 3, and every subsequent position
is the next prime. As an example, the note A#+ would
be represented as v = {2,2} and would be calculated
as n = r(32 52). This can be seen in Figure 6 by com-
paring the positions of G and A#+ relative to C.
We designed an alternative vector representation
of a Johnston note, which is our representation of
choice in Ammmp. Specifically, we chose to repre-
sent any given note as a tuple <c, v>, where c is a
note name and v is a vector of accidentals. Thus,
our representation of Johnstons language ignores
lattice relationships and stores only the note name
and the number of accidentals into a tuple. The first
position of the vector, v, is equivalent to the num-
ber of syntonic commas, the second the number of
sharps, the third the number of sevenths, the fourth
the number of arrows (elevenths), and so on.
As an example, for the tuple <G, {1}>, the note
would be G+. Similarly, <G, {1,2}> would be Gx,
pronounced G minus double sharp. This represen-
tation has the advantageous property of using vector
addition to change accidentals. In the computer,
changing from Gx to G# reduces to adding the
vector {0, 1} to the previous note. This vector repre-
sentation will be used for the rest of this article.
Translation Algorithms
Translating from Johnston to Performance
To create new musical languages in Ammmp, and
translations for them, several steps must be taken.
First, an AbstractNotation object must be created,
which represents the mathematical meaning of a
musical language, aside from the graphics. Second,
an AbstractNotationConverter object must be cre-
ated, which literally translates two notation objects.
In this section, we present an algorithm translating
from Johnstons musical language to performance
notation.
Translating from Johnstons musical language
into performance notation is, essentially, the pro-
cess of translating the note and its accidentals into
cents values. This translation requires that we de-
fine several equations and variables. The first equa-
tion we define is the usual function for translating a
ratio x to cents p as
p(x) = log2(x) 1200 (2)
where x is a real number.
Stefik et al. 39
 Figure 7. Accidentals used
in Ben Johnstons musical
language, expanded to a
61-limit system from
Fonville (1991). The cents
values are approximate.

We also must define a separate vector j for this

conversion. The vector j consists of the ratios for all
elements in v. For example, j[0] = 81/80, the syn-
tonic comma, and j[1] = 25/24, a sharp. Figure 7
shows a 61-limit list of Johnston accidentals. Thus,
each element of j corresponds to the ratio represen-
tation of an accidental in Ben Johnstons language.
Assuming the note C in Johnstons language has a
constant value of zero cents, and recalling in our
<c, v> tuple that c is the ratio of a note and v is the
number of accidentals, the equation for translating
from Johnstons language to performance notation
is given by
n1

cents = r p c j[i]v[i] (3)
i =0
Owing to memory-overflow issues, it is often
convenient to first convert ratios into cents values.
Thus, for this next equation, we define the vector h,
which contains the cents value of a ratio represent-
ing a Johnston accidental. For example, if j[0] =
81/80, then h[0] = p(81/80) = log2(81/80) 1200
21.506. With cents values now in h, we can add the
values of each element in h and add the value of the
note c, giving the performance notation value. This
yields

(h[i] v [i])
n1
cents = r p(c) + (4)
i =0

For example, if we have the tuple <1/1, {1}> the

note would have the ratio 1/1 81/80, the value of
one syntonic comma, and thus the final note would
be C+ in Johnstons language. Using the first equa-
tion, translating to performance notation then gives
p(1/1 (81/80)1) = p(81/80) 21.506. As expected,
using the second equation gives the same value,
p(1/1 + (p(81/80) 1) 0 + (21.506 1) 21.506. Simi-
larly, given a tuple <5/3, {1,1,1} >, the note value
would be A#7. This yields p(5/3 (81/80)1
(25/24)1 (35/36)1) 884.8, approximately an A on
the modern piano minus 15.2 cents.
Although the ratio 35/36 may appear to be a typo-
graphical error, recall that the accidental of a 7 in
Johnstons language actually indicates a downward
pitch bendnot upward, like most other acciden-
tals. This is not unique in Johnstons language. The

40 Computer Music Journal


accidentals for 19, 47, 53, and 59 also indicate
downward pitch bends.
Last, it is important to remember that these
equations translate only a single note in Johnstons
language into performance notation. The entire con-
version process must iterate over all notes in a given
score. In Ammmp, we limit the vector v to some
constant size, largely because using higher limit
accidentals in the Johnston system is uncommon.
Thus, we define v n, and we choose n = 17, indi-
cating a 61-limit system. Because each vector is of
constant size (17), the upper bound of our algorithm
has a running time linear to the number of notes.
Translation from Performance to Johnston
Creating a performance-to-Johnston translator re-
quires only one addition in the Ammmp architec-
ture, a new AbstractNotationConverter object. In
this section, we discuss the algorithm used in this
object. Notice that, in the previous translator, there
is a simple equation that reduces a note and its
accidentals into a cents value in performance nota-
tion. Now consider the opposite case: translating
from performance notation to Johnstons language.
The fundamental issue is to take a value from per-
formance notation, a real number x, where x 0
and x < 1200, and translate it into the correct num-
ber of accidentals for the correct note in Johnstons
language.
Mathematically, the problem is to translate a real
number x to a tuple <c, v>, where c is a note and v is
a vector of accidentals. We define v as having a fi-
nite size, essentially limiting v n. Unfortunately,
in practice, this translation is imperfect.
We now present an example of the lost in trans-
lation problem. Suppose c1 = {1/1} and v1 = {0,0,1},
which represents the note C7 in Johnstons lan-
guage. Also, suppose we translate <c1, v1> to perfor-
mance notation, making x 1151.
Now suppose that we translate x back to some
<c2, v2>, where we do not know the original <c1, v1>,
and that we arbitrarily select the size of v2 to be 2, or
v2 2. Therefore, because we have limited v2 2,
we have made it impossible to retrieve the original
Figure 8. An example mea-
sure from Toby Twinings
Chrysalid Requiem (Twin-
ing 2002). Used by permis-
sion of Toby Twining
Music, all rights reserved.
meaning, since v1 3. In this instance, Ammmp will
determine some <c2, v2> where x 1151, but v1 v2.
Thus, in effect, although the sound is the same, the
original vector was lost in translation.
Although this lost in translation problem is
troublesome, another concern of translation is
equally important: complexity. A given note in
Johnstons language can either be simple, like C =
1/1, or complex. It is important to avoid complex-
ity, as a greater number of accidentals decreases
readability. Thus, we present another equation that
defines what we mean by complexity. Complexity
is defined as
n1
comp(v) = v[i] (5)
i =0
for some vector v. This complexity equation states
that we add the absolute value of each v[i], giving
the total complexity of the note. For example,
comp({1,1,5}) = 7 and comp({1,2,3}) = 6. Intuitively,
measuring complexity is important because users
prefer to read notes with few accidentals.
As a real-world example of the lost in transla-
tion problem that also highlights the importance
of considering complexity during translation, we
present one measure of a score by composer Toby
Twining. Figure 8 shows a particularly complex
measure of Twinings Chrysalid Requiem (2002),
using one version of his notation. In the language
we have been using until now for representing
pitches, we can say that Twining uses v 3, where
the first note has the tuple <F, {9,9,28}> and the
second note has the value <G, {8,9,27}>. This gives
the first note a complexity rating of 46 and the sec-
ond note a rating of 44, a complicated section of
music. We ran this section of Twinings score
through Ammmp with various table sizes and val-
ues of n in v n, the results of which are in Table
1. Figures 9 and 10 show how the complexity values
change in relation to the original music score with
various vector sizes.
Stefik et al. 41
Figure 9. Graph showing Figure 10. Graph showing for the 12,000-element
the complexity of the note the complexity of the note table with v 1, because
<F, {9,9,28}> before and <G, {8,9,27}> before and the value is much larger
after translation. after translation. This than the others (1064).
graph omits the data point

Table 1. Results of Translating Two Notes from Toby Twinings Chrysalid Requiem
Table Size |v| <F, {9,9,28}> Complexity <G, {8,9,27}> Complexity

1,200 1 <D, {97}> 97 <G, {27}> 27

12,000 1 <D, {97}> 97 <D, {1064}> 1064
1,200 2 <A, {3,2}> 5 <D, {6,3}> 9
12,000 2 <E, {10,13}> 23 <G, {4,7}> 11
1,200 3 <A, {3,2}> 5 <B, {2,2,1}> 5
12,000 3 <F, {3,7}> 10 <G, {4,7}> 11
1,200 4 <A, {3,2}> 5 <B, {2,2,1}> 5
12,000 4 <C, {0,3,1,1}> 5 <D, {1,3,2,1} 7

In general, when translating the case of v n,
n > 1, we found our translated pitches to be far sim-
pler than this version of Mr. Twinings score. The
fact that for n = 1 the complexity was very high is
not surprising, as this implies it would take a num-
ber of syntonic commas to yield the same pitch that
the composer uses.
With tools in place for analyzing the complexity
of a note, vectors representing approximations to an
original pitch value, and a real-world example, we
now demonstrate the Ammmp translation algo-
rithm. In essence, Ammmp pre-processes a large
table and stores a Johnston value for any particular
performance value. This allows us to query by a per-
formance value in the table, retrieving a very close
approximation of the original Johnston note.
This approach works in Ammmp but does require
a good deal of memory for the translation table. For
a translation with a decimal places of accuracy, we
need to store 1200 10a entries in our table. Thus, a
table that is accurate down to 0.1 cents requires a
table with 12,000 entries.
The first step in the translation algorithm in-
volves generating vectors. Recall that vectors in this
system consist of integers of any size, positive or
negative. Also recall that we would prefer to gener-
ate vectors with low complexity, which we accom-
plish using a counting algorithm. The only exception
in our case is to determine a bound on counting and
to allow negative numbers while counting. The first
condition is met by allowing the user to set an arbi-
trary bound. Essentially, this means Ammmp will
consider accidentals with 2, 3, or n sharps before
considering an accidental beyond the sharp. The
second condition is trivial. Instead of counting in
the usual way (1, 2, 3, 4, 5, etc.), we count our vec-

42 Computer Music Journal


tors as 0, 1, 1, 2, 2, 3, 3, and so forth. For example,
if our bound is 1, and v 2, then we might count
{0}, {1}, {1}, {0,1}, {1,1}, {1,1}, {0,1}, etc. Future
work may explore these counting algorithms further.
The next step of the algorithm involves generat-
ing the Cartesian product M = v Notes, where
Notes = {A,B,C,D,E,F,G}. Now consider the simplest
of all vectors in this system, v = {0}. The Cartesian
product then gives the following tuples: <A, {0}>, <B,
{0}>, <C, {0}>, <D, {0}>, <E, {0}>, <F, {0}>, and <G, {0}>.
The philosophy behind this part of the algorithm is
to add sets of elements to the table that are simple
first, then generate more complex sets. Because we
know that {0} is as simple as possible, we generate
all possible notes with that vector.
The third step of the algorithm is the conversion
of the tuple <c, v>, in Johnstons language, into x, or
performance notation. This step is the same as the
conversion from Johnston to performance notation
discussed in the previous section. After x has been
calculated, we can then calculate its final position
in the table. If the final cents value of the note is x
and our desired table accuracy is a, then our final
position can be calculated by p = x 10a. As an ex-
ample, if x = 78.345 and a = 3, then we know our
table size is t = 1,200,000 = 1,200 103 and our final
position, p, is p = x 10a = 78.345 103 = 78,345. The
final step of the algorithm is to repeat the above steps
until the table is filled.
To evaluate this algorithm, we ran several simula-
tions for generating the table. We ran simulations for
tables of size 1,200, 12,000, 120,000, and 1,200,000.
For each table size, five simulations were run, and
the average time to fill the table was recorded for
each run. In addition, we tracked the total number
of calculations required to fill the table.
Because Ammmp accounts for approximate val-
ues of x, collisions to positions in the table occur.
Collisions can be handled by either choosing the
value with the lowest complexity, eliminating the
colliding value, or a heuristic. We chose the simplest
of the approaches and eliminate the new value. In
future work, we may compare this approach to a
different collision-handling mechanism. Here, we
tracked the average number of collisions in the en-
tire table and the average number of collisions be-
Figure 11. Total time to
create various precision
tables for translating from
performance to Johnston
notation.
tween ranges of notes. Data such as this helps to in-
dicate how often collisions occur in table genera-
tion and also whether certain notes are more
difficult to fill in the table than others.
Timing for each run begins when the first vector v
is generated and continues until the table is filled.
Figure 11 shows the results of the simulation times.
The time appears to increase exponentially as the
table size increases. Figure 12 shows the average
number of collisions that occur for each cell in the
table. Because we know that collisions are in-
evitable, and because x is an approximation, we
track these collisions in comparison to the size of
the table. In general, collisions increase as the table
size increases, and their number appears to be rela-
tively linear with the size of the table.
In addition, information was extracted from the
algorithm to derive collision data between ranges of
notes. Dividing the table into twelve parts gives the
usual notes on the piano. Figure 13 gives a closer
look at collisions in each area of the table. Interest-
ingly, Figure 13 suggests that for smaller tables it is
more difficult to fill the regions located around the
notes C and F.
The benefit of this approach is that translating
back into Johnstons language is O(1) for each note
in the score. This makes the total algorithm O(n)
for any arbitrary number of notes, after a table has
been generated one time.
One might ask why we chose table generation
and reference-based algorithms over continued frac-
Stefik et al. 43
Figure 12. The average
number of collisions per
cell in the conversion
tables.
tions and prime factorization. Although it is likely
possible to find a solution using factoring methods,
table-generation techniques like ours have signifi-
cant benefits. First, table generation is fast for small
tables and must be run only one time. Once a table
is created, each individual note can be translated in
O(1). Further, using an algorithm such as ours to
control how the table is constructed allows us to
use minimization techniques to limit the complex-
ity of individual notes.
Additionally, this algorithm also allows us to cus-
tomize the table for accidentals that humans would
likely prefer to see. For example, our table should be
filled with sharps and flats before upside-down
numbers and arrows, as these accidentals are less
common and more difficult for a human to under-
stand. It may be possible to take all of these consid-
erations into account with prime-factorization
approaches, but we found this alternative to be sig-
nificantly more complex.
Translators Unrelated to Tuning
To show the generality of our architecture, we also
implemented two additional languages and transla-
tors between these and all previously discussed
systems. These two systems include a language rep-
resenting standard Western, non-microtonal nota-
tion, and a chromatic staff invented by Grace Frix.
Many variations exist on the idea of a chromatic
44
Figure 13. Average number
of collisions between
notes.
staff, including one suggested by Arnold Schoen-
berg, although the core idea is to remove the need
for accidentals by making individual lines and
spaces chromatic pitches. Several examples can be
found at the Music Notation Modernization Associ-
ations Web site at www.mnma.org. We chose Grace
Frixs variation largely because it did not require us
to create new fonts or graphics in Ammmp.
Adding different musical languages into Ammmp,
assuming a good understanding of music notation,
is fairly easy. Because no new art was needed,
adding these two additional languages took one
programmer a few hours. Additional components in
Ammmp, like the custom synthesis engine and for-
matting algorithms, automatically adapted to the
new musical languages without modification.
Conclusion
The principal contribution of this work is to intro-
duce the idea of translating between music lan-
guages, including a musical version of the phrase
lost in translation. It is unfortunate that a great
deal of research has been done in translation of nat-
ural language, yet musicians analyzing historical
texts must work more or less by candlelight, with-
out technological assistance or guidance. We intend
to help in this regard by creating Ammmp, a frame-
Computer Music Journal
work for musical language translation. It is our hope
that future researchers will consider musical-
language translation for other types of musical lan-
guages, perhaps neumes, mensuration symbols, or
any of the complex musical languages developed in
the 20th and 21st centuries.
For future work, we intend to explore methods al-
lowing other researchers to plug into Ammmp,
simplifying the process of adding new musical lan-
guages. In addition, it may be fruitful to design cat-
alogs of musical languages in terms of how well
they translate to other languages, and whether the
translation occurs by approximation or whether it
is exact. Another goal we have considered is creating
a semantic map for music, where any known lan-
guage can be plugged into the map, and then auto-
matically translated to any other known language.
Although these are lofty goals, we see this article as
a first step on the road toward musical language
translation.
References
Barbour, J. M. 1951. Tuning and Temperament: A Histori-
cal Survey. East Lansing, Michigan: Michigan State
College Press.
Bellini, P., and P. Nesi. 2004. Automatic Justification and
Line-Breaking of Music Sheets. International Journal
of Human-Computer-Studies 61(1):104137.
Blostein, D., and L. Haken. 1991. Justification of Printed
Music. Communications of the ACM 34(3):8899.
Brandorff, S., M. Lindholm, and H. B. Christensen. 2005.
A Tutorial on Design Patterns for Music Notation
Software. Computer Music Journal 29(3):4254.
Brown, A. F. R. 1958. Language Translation. Journal of
the ACM 5(1):18.
Chalmers, J. 1992. Divisions of the Tetrachord. Lebanon,
New Hampshire: Frog Peak Music.
Doty, D. B. 1994. The Just Intonation Primer: An Intro-
duction to the Theory and Practice of Just Intonation.
San Francisco, California: Just Intonation Network.
Fokker, A. D. 1949. Just Intonation and the Combination
of Harmonic Diatonic Melodic Groups. The Hague: M.
Nijhoff.
Fonville, J. 1991. Ben Johnstons Extended Just Intona-
tion: A Guide for Interpreters. Perspectives of New
Music 29(2):106137.
Gamma, E. , R. Helm, R. Johnson, and J. Vlissides. 1995.
Design Patterns: Elements of Reusable Object-
Oriented Software. Boston, Massachusetts : Addison-
Wesley.
Good, M. 2001. Musicxml: An Internet-Friendly Format
for Sheet Music. Paper presented at the XML 2001
Conference, Orlando, Florida, 914 December.
Gourlay, J. S. 1987. Spacing a Line of Music. Technical
Report. Columbus, Ohio: Department of Computer and
Information Science, The Ohio State University.
Gourlay, J. S., et al. 1987. Computer Formatting of Mu-
sic. Technical Report. Columbus, Ohio: Department
of Computer and Information Science, The Ohio State
University.
Hajic, J., J. Hric, and V. Kubon. 2000. Machine Transla-
tion of Very Close Languages. Proceedings of the Sixth
Conference on Applied Natural Language Processing.
Seattle, Washington: Morgan Kaufmann, pp. 712.
Haken, L., and D. Blostein. 1995. A New Algorithm for
Horizontal Spacing of Printed Music. Proceedings of
the 1995 International Computer Music Conference.
San Francisco, California: International Computer Mu-
sic Association, pp. 118119.
Hegazy, W. A., and J. S. Gourlay. 1987. Optimal Line
Breaking in Music. Technical Report. Columbus,
Ohio: Department of Computer and Information Sci-
ence, The Ohio State University.
Johnston, B. 1964. Scalar Order as a Compositional Re-
source. Perspectives of New Music 17(2):5676.
Johnston, B. 1976/1977. Rational Structure in Music.
American Society of University Composers 12:
102118.
Johnston, B. 2006. String Quartets Nos. 2, 3, 4, and 9.
New York: New World Records. Audio compact disc
80637-2.
Jorgensen, O. H. 1991. Tuning: Containing the Perfection
of Eighteenth-Century Temperament, the Lost Art of
Nineteenth-Century Temperament, and the Science of
Equal Temperament Complete with Instructions for
Aural and Electronic Tuning. East Lansing, Michigan:
Michigan State University Press.
Locke, W., and D. Booth, eds. 1955. Machine Translation
of Languages: Fourteen Essays. Cambridge, Massachu-
setts: MIT Press.
Parrish, A., and J. S. Gourlay. 1987. Computer Format-
ting of Musical Simultaneities. Technical Report.
Columbus, Ohio: Department of Computer and Infor-
mation Science, The Ohio State University.
Partch, H. 1974. Genesis of a Music. New York: Da Capo
Press.
Stefik et al. 45
Raman, S., and N. Alwar. 1990. An AI-Based Approach
to Machine Translation in Indian Languages. Commu-
nications of the ACM 33(5):521527.
Stone, K. 1980. Music Notation in the Twentieth Cen-
tury. New York: Norton.
46
Twining, T. 2002. Chrysalid Requiem. Brooklyn, New
York: Cantaloupe Music. Audio compact disc,
CA21007.
Whitney, P. 1998. The Psychology of Language. Boston,
Massachusetts: Houghton Mifflin.
Computer Music Journal