I was rereading Lydia Goehr’s The Imaginary Museum of Musical Works the other
evening after a long day spent translating several of
music21’s
score-representation code packages from Python to JavaScript (for
music21j). What struck me when I was reading the introduction, which
lays out several pre-existing theories about the work-concept, and the
relationship(s) among the musical idea, the building blocks of scores
(pitches, etc.), the score-copy, and performances, was my own need to
take a stand on the proper relationships of such conceptions when
choosing a computational language in which to express musical languages.
Those who haven’t programmed may not know that no modern computer
program (or very very few) is built from a single code file, or
flowchart leading from input to output. Instead each program is built
from components (a file browser, a set of functions for manipulating
canvases for drawing, a module for representing tempo) that can be
called upon by other components in a systematized but reusable and
testable manner. These get bundled or packed or linked together to
make a complete or extensible application or library. Different
philosophies exist about which structures (or ontologies, to use a
word with related but quite different meanings between the humanities
and computer science) can be well-formed or desirable.
These philosophies about file linking—importing and exporting—lie
close to the marrow of the designs of various computer languages and in
many cases evolved in response to the environments within which the
languages were originally created. Python, a language run on
individual computers that came of age in the era of fast hard drives
and, from the user’s perspective, near instantaneous loading of small
files, aims to put as few limitations on the possible relationships
between modules as possible. JavaScript, on the other hand, which
appeared first on the web in the time of dialup internet and unreliable
connections, has, even in its most recent incarnations, placed sharper
restrictions on connecting resources in the name of efficiency.
Translating music analysis software from the first language to the
other has raised complex problems for the representation of music in
code. Python allowed me to interweave different levels of musical
thought, such that notes could will into existence a measure (say by
asking for the creation of an object to encompass them) while a measure
could in another context give birth to notes (for instance by asking
for a suitable number to fill it, given some metrical, harmonic, and
accentual constraints). A score could of course be a container to many
measures, but a measure could also be linked or contain many scores
(for instance as a key or heading to a catalogue of quotations or
standard topoi). As I created the original music21 in Python, I reveled
in the multiplicity of possible relationships, in the way some musical
philosophers might argue that a score gives rise to a performance
which, if transcribed or imagined, gives rise to a new score, which
gives rise to a new performance, and so on to infinity.
Rewriting the “same code” posed, and continues to pose, a challenge to my
ecumenical notion of musical relationships. (With “same code” in
quotation marks since the work-concept-concept for computer works has
not been the subject of nearly so much rumination.) In JavaScript, in
order to make sure that everything has been loaded before the user
closes her browser in frustration, in general if one module (A) uses
another module (B) in its code, then the second module (B) cannot use,
or import, the first (A) into its code. What some, perhaps those trained
as humanists, might exult as a beautiful web of inter-compu-textuality,
is called a cyclic or circular dependency and it is easy to find
categorial pronouncements that such things are
bad or the result of lazy or sloppy thinking. They
resist creating a hierarchy of elements, and prevent creating beautiful
tree structures that are, or at least were during the time when
computers were problem-solving devices and not enablers of exploration,
the key to moving in an efficient manner from point A to point Z without
getting into an endless loop somewhere around J to M. (A programmer—who
had apparently gotten too deep into the trenches of coding to remember
that the terms which undergird so many computational structures are
metaphors—once criticized a part of my code that had many pointers
running up and down a hierarchy by saying, “This is absurd! A child
cannot have more than one parent.”)
In Python, I could say that a Note in the presence of another Note
created an Interval. (Like in German, in most computer languages, nouns,
or Objects, are capitalized.) And, I could simultaneously say that an
Interval, given a starting Note for reference, could define a second
Note that fulfilled it. Both of these generating relationships seemed
not just plausible, but natural and essential to a full representation
of the complexity of music. The ambiguity of which came first, the
interval or the note can never be resolved. In JavaScript, however, the
programming musicologist is left with a decision to be made: either
Notes can create Intervals or Intervals can create Notes, but not both.
The work creates the score (or performance), or the performance or the
score creates the work, but not both. The one who is able to create both
Notes and Intervals is an entity that stands outside the system—the
calling program—which is perhaps better named “the observer” in the
best literary criticism traditions, since the network of Notes and
Intervals cannot operate with knowledge that it exists.
(To be fair, there are some complex and fragile ways to work with
circular dependencies in JavaScript, and in Python, true circular
dependencies are also impossible: either the Note can only become aware
of its ability to create Intervals at the moment of action [an import
nested in a method] or vice versa.)
I have found that programming musical logic has sharpened my awareness
of the ambiguities, hierarchies, and underdefined elements of music. By
underdefined elements, I suggest: is the interval from E# to Fb an
ascending doubly-diminished second or a descending doubly-diminished
second? If spelling matters more than sound, such that C-G is consonant
but Dbb-G is dissonant, is the bass of a chord beginning on
E##-Fbb-Bb the E## or the Fbb? (If it’s the Fbb, then is a
B###-Dbbb-F# chord in root position or first inversion? If the E##,
does that mean that we cannot determine the bass of a chord by ear?)
These may be absurdities to practicing musicians but deciding a “right
answer” to them makes all the difference in how standard musical
relationships should be represented and encoded.
It is extremely difficult to tell a computer to hold off on making a
decision or to leave a paradox in place to solve later. The human
ability (flaw?) in being able to reason around ambiguity, or to hold
conflicting ideas without breaking down, is a capacity that those who
design practical computing systems have either not been able to
replicate or have deliberately chosen not to. Within the limited
choices, I have generally been drawn to computing frameworks that let
me come as close as possible to representing multiple perspectives.
(Ironically, I’ve found the closest match so far in Python, despite its
community adopting a motto that says there should be only one way to do
it.) There is a danger that when good but still inadequate tools are
used to model human behavior and creativity, eventually human behavior
will bend to suit the tools, rather than the other way around. It is a
force that those who design and use these tools must be aware of and
continually fight against.
(updated 2022.02.03 — corrected "revealed" to "reveled")
(updated 2026.02.08 — correct minor grammar issues, fixed broken links.)
(updated 2026.02.08 — correct minor grammar issues, fixed broken links.)
