Linear Music Code

Background

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.

Elements

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).

Syntax

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?

• In the first place, linear music code is readable while SCORE code is not. All the facts about a note (more precisely, a note-head) are there with the letter name. No need to cross-correlate with the text stream that holds the durations. In truth the process of converting linear music code back to graphical score notation is just as intuitive as the original encoding effort.
• In the second place, linear music code is much more character-efficient than SCORE code:
  • This is partly because durations and octaves default to what happened previously, so the encoder needs not repeat attributes which carry over.
  • Also contributing to the inefficiency of SCORE code are the delimiters (typically forward slashes) which separate consecutive attribute items. This convention alone doubles the number of characters necessary to encode a musical passage using SCORE.
• In the third place, linear music code is much less error prone than SCORE code:
  • When total of durations in a “voice line” did not sum to the measure duration, Ashton's processor would tell you so. Because SCORE code does not impose a metric context, the separate text streams which encompass a voice line typically extend over entire sections. This makes locating rhythmic errors much harder, especially since (as I recall) the Smith's processor did not check durations.
  • Worse, if one unintentionally omits an attribute item then the output is subject to phasing errors, where for example the pitch intended for one duration gets applied instead to the duration's successor. Smith's program did give notice when mismatches occured between text-stream item counts, but in complex passages I sometimes found it impossible to track down the missing value.
• SCORE did have the advantage over the linear music code as regards articulation. All the linear music code offered was the “staccato” option indicated in Figure 1 (a) using the circumflex (shift-6), which Kowlton's teletype printed as up-arrow character. This indication caused subsequent sounding durations to last half as long as the notated period between consecutive attacks. SCORE, by contrast, offered a “duty factor” approach: A separate text stream could be provided indicating percentage relationships between sounding durations and notated periods. Further considerations on the encoding of articulation are discussed in connection with my score framework.

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.