Linear Music Code


During the early 1970's several graduate students at the University of Utah collaborated on a project to interface a computer to an electric organ. This project became the basis for separate Ph.D. dissertations by Alan Ashton and by Prentiss Knowlton, also a Master's thesis by David Ashton. The project's musical advisor was Vladimir Ussachevsky.

Knowlton described the project in a May 1972 Datamation article, “Capture and Display of Keyboard Music”. Among other things, this article presents a text encoding of nine measures of two-part counterpoint (by Bach) alongside CRT images of musical notation rendered from these samples. Knowlton's article states Alan Ashton “designed the music description language”.

Alan Ashton went on to develop WordPerfect, a popular WYSIWYG text-processor.

Prentiss Knowlton landed a job at the Jet Propulsion Labratory in Pasadena, California. By 1976 the system had been adapted to a pipe organ; Knowlton described these adaptations at a Midcon/77 presentation entitled “Musical Sculpture by Minicomputer”. The brain of this adapted system was a PDP-8 minicomputer which read in real time from paper tape and converted text from linear music code into timed note-on/note-off commands.

Knowlton hooked up his PDP-8 to the ”ninety-rank Shlicker pipe organ“ in Pasadena's All Saints Church and in 1976 produced two LP recordings titled Unplayed by Human Hands and Unplayed by Human Hands in Concert. These recordings are notable for their total lack of attention to nuance.

I personally became acquainted with Prentiss Knowlton during 1977 when he was attempting to upgrade the PDP-8 to an IMSAI-8080 microcomputer and to interface the system to a “Mighty Wurlitzer” theatre organ at the Crown Theatre in Pasadena, California. These projects never came to completion, but for a time I did have the opportunity to work with the PDP-8 using Knowlton's own pipe organ, which was set up in an audience box. The documents reproduced as Figure 1 (a-b) and Figure 2 below were provided to me by Knowlton, but I don't believe he actually authored them. Many features present in Figures 1&2 were not evident in the 1972 Datamation article; for example, chords, tuplets, accelerations/ritards, and crescendi/diminuendi.


The linear music code provides a means of resolving a complex musical texture, wherein many things are happening at the same time, into a linear stream of characters. In that sense, the linear music code provides an early historical instance of serialization. The code is highly compact, but also very readable. The characters are the subset of ASCII available from a teletype keyboard (no lower case letters). Whitespace is ignored, including line terminators. Printable characters have the specific meanings detailed in Figure 1 (a-b).

Figure 1a: Symbol key for the linear music code (page 1).   Figure 1b: Symbol key for the linear music code (page 2).


Figure 2 illustrates how a musical excerpt would be transcribed. The cleverness of Ashton's approach is better evident by comparison with the SCORE program by Leland Smith of Stanford University, and which latter was being used as a preprocesser for MUSIC-N style sound synthesis. In SCORE, note attributes such as pitch, duration, loudness, and articulation, was input using a separate text stream. With the linear music code, by contrast, everything centers around the letter name. Thus while the first note in a measure requires explicit duration, letter name, and octave; subsequent durations and octaves are necessary only when something changes.

Figure 2: Music notation example.

Why is Ashton's approach cleverer?

Leland Smith mentioned the University of Utah's competing typographic solution when he presented SCORE at Stanford summer workshop which I attended. Smith had not been impressed by the graphic output from Ashton & Knowlton's project, which crudely represented note heads using squares rotated by 45°. Challenged about his decision to separate note attributes into separate text streams, Smith explained that this decision was taken in order to support serial manipulations. In particular, pitch sequences could be stored under named symbols. Then when you brought back a sequence you could transpose it or present the sequence in retrograde order.

© Charles Ames Page created: 2017-03-12 Last updated: 2017-03-12