Generating Music Notation in Real Time

Composers from a variety of backgrounds have been interested in having greater freedom in musical performances. This article describes another attempt in this tradition.

In his Klavierstcke, Karlheinz Stockhausen allowed performers to order prewritten material as they saw fit. Earle Brown allowed conductors to mix and match material in his Available Forms pieces, and in his graphic scores, he allowed performers essentially to improvise whatever the images in the score inspired them to play. Improvisation obviously is critical to jazz, as well.

In all of these examples, the composer gives this increased freedom only to performers or the conductor, not to the audience. My doctoral dissertation piece No Clergy and its associated programs constitute one attempt to give similar freedoms to the audience.

In No Clergy, performers play on-screen notation presented through a Web browser. The audience has Web browsers open to pages with standard CGI forms, allowing them to react to what they're hearing by entering data. The piece's scripts then process the data, affecting the subsequent pages of notation presented to the performers.

No Clergy has specific technical, logistical and esthetic requirements. The processing must occur in real time. The audience's and performers' interfaces for the piece must be familiar and comfortable. The piece must be transportable—able to be performed in any location with minimal setup requirements.

The user, who serves as the “conductor” and is either me or someone filling a similar role in a performance where I am absent, starts the piece by running the bash script setup.sh. The script generates, with Python, a markup file for GNU Lilypond, a music typesetting program described in greater detail later in the article. It then processes that Lilypond file into a PNG image, as shown in Listing 1. Portions of the script that are not shown also perform cleanup actions to remove old data and ending actions to place images in the appropriate Web directories.

python -O NoClergy/Python/make_ly.py \
clar > lilypond/ly/clar.ly
lilypond --png -o lilypond/out/ lilypond/ly/clar.ly

Figure 1. Sample Initial Output for a Clarinet

Later, when user data are available, a similar bash script called noclergy.sh (Listing 2) reads the previous data and generates subsequent pages of notation. The script mutate_config.py reads the user data and updates a config file, while mutate.py applies those changes to the musical material, performing actions similar to the setup.sh script described above, but this time with a previous example of output from which to work.

python -O NoClergy/Python/mutate_config.py
python -O NoClergy/Python/mutate.py 'lilypond/ly/'

I chose an object-oriented paradigm because the musical material contains multiple instances of similar types of data. Initially, the top-level Class was Score, defined as one page of notation for one instrument. Each Score has a transposition level appropriate for its instrument and can contain an arbitrary number of Measures. I chose 20 as good number of Measures to fit comfortably on a single page with reasonable legibility, and as a good duration of musical time between each updated page of notation.

Each Measure has a meter, which determines how long it is and its internal rhythmic organization. It contains however many Notes fill that meter. The total number of Notes also varies based on each Note's duration.

A Note is defined as an individual sound or silence event within a Measure. It has a string called pitch, which is either r for a rest or an indication of its pitch class, such as c, cs for C sharp, d or ef for E flat. It also has an integer called octave, which is meaningful only for non-rests.

Notes also have durations, dynamics, which are variations in amplitude or volume, and articulations, which determine whether the note is accented, detached or sustained into the next note, among other things. Notes also can be tuplets, which are a particular type of rhythmic organization.

Tuplets are notes or rests that occur at a different rate than their note type would indicate. By far, the most common type of tuplet is the triplet. A set of three triplets occupy the same duration as two notes, so three 8th note triplets occur in the span of two normal 8th notes, or one beat in most instances. Quintuplets are five notes in the span of four, septuplets are seven in the span of four and so on. Unless otherwise indicated, a set of tuplets squeezes x notes in the span of y, where y is the highest power of 2 lower than x. Composers generally indicate deviations from this practice with x:y notation on the tuplet set, so a 7:8 tuplet set stretches seven notes across the span of eight.

No Clergy uses a non-unique list of tuplet types—the number indicated by x in the preceding paragraph. This allows me to weight in favor of triplets and quintuplets, as is common. Anyone who wants to use my program to sound like Frank Zappa or Brian Ferneyhough can alter the tuplet list as they wish, although musicians should know that this initial version of the program does not yet support nested tuplets. Non-musician programmers probably can discern from the name that nested tuplets are sets of tuplets that themselves contain one or more sets of tuplets. The program also does not yet support dotted notes, which use a notation convention to show that a note should last half again as long.

When the scripts generate notation, they read a configuration file, updated by the mutate_config.py script mentioned above. The various pc variables shown in Listing 3 represent the percentage chance that a given note will have the characteristic in question, such as being a tuplet, being a rest as opposed to a note that sounds, having an explicit dynamic mark and having an explicit articulatory mark.