Music as code talks

I've been giving talks about music theory and code for a few years now, so I thought I'd collect them all together in one place. They are based on Overtone and my Leipzig music composition library.

1. Functional Composition, about music theory from sine waves through to canons, given at Lambda Jam 2013 (code).
2. Kolmogorov Music, about music and complexity theory, given at Strange Loop 2015 (code).
3. Dueling Keyboards, about temperament and tuning systems, given at Clojure eXchange 2015 (code).
4. Klangmeister, about my online live coding environment, given at FlatMap 2016 (code).
5. African Polyphony and Polyrhythm, about music from the Central African Republic, given at Strange Loop 2016 (code). Slides are online.
6. It Ain't Necessarily So, about the psychology of musical perception, given at Curry On 2018 (code). Slides and demo are online.
7. Birdsong-as-code, about the music theory of birdsong, given at Strange Loop 2023 (code).

 If you're interested in my personal music, check out Whelmed (code) or this performance with keytar accompaniment.

GEB

Douglas Hofstadter's Godel, Escher, Bach is one of my favourite books. Commonly referred to as GEB, this book is a mesmerising meditation on consciousness, mathematics and creativity. The central idea is that of a "strange loop", in which the same message is interpreted on multiple semantic levels.

GEB was the first place I came across the idea of a musical canon. A canon is a beautifully austere form of composition that was popular in the Baroque period. A canon consists of a dux part which sets out the base melody accompanied by a comes part which is some kind of transformation of the dux.

Here is the structure of a canon described using the programming language Clojure. f stands for the transformation selected by the composer.

(defn canon [f notes]
  (->> notes
       (with (f notes))))

For example, the comes might be formed by delaying the dux by a bar and raising every note by a third. In my talk Functional Composition I show how computer code can be used to explain music theory, focussing on JS Bach's Canone alla Quarta from the Goldberg Variations. Canone alla Quarta is an unusually complex and beautiful canon where the transformation is composed of a delay of three beats (a simple canon), a reflection (a mirror canon) and a pitch transposition down a fourth (an interval canon).

Here is the transformation from Canone alla Quarta written in Clojure. comp is a Clojure function for composing multiple transformations together.

(defn canone-alla-quarta [notes]
  (->> notes
       (canon
         (comp (interval -3) mirror (simple 3)))))

I was working on a talk for last year's Strange Loop programming conference (itself a reference to Hofstadter's work) and I decided that I wanted to create my own canon as a tribute to GEB as a finale. Rather than use an ordinary musical transformation for my comes, I wanted to pick something that spoke to the idea of composing music with computer code. I also wanted to incorporate GEB's theme of interpreting messages on multiple levels.

I took the letters G, E and B, and used the ASCII codes that represent these letters as though they were MIDI pitch codes. This gave me my dux. I then took the same three letters and interpreted them as the musical notes G, E and B. This gave me my comes. I had obtained a canon based not on musical concepts like delay or transposition, but on encoding schemes used in computer programming.

(defn canone-alla-geb [notes]
  (->> notes
       (canon
         #(where :pitch ascii->midi %))))

I elaborated the harmonies provided by this canon into a complete track, composed via computer code. The dux and the comes are joined by various other parts, some using polyrhythms to generate apparent complexity from underlying simplicity.

Eventually, the dux and the comes are accompanied by a third canonic voice, in which the names of Godel, Escher and Bach are read out by a text-to-speech program. So the theme of three notes G, E and B becomes a canon of three voices musical, technical and allusive to the three great creative spirits Godel, Escher and Bach.

Listen to the recording.

Read the code.

Watch the talk.

Hiding the REPL

I depend heavily on Clojure's REPL, because it's where I write music. Over time, however, I've become less focused on directly interacting with the REPL, and pushed it more and more into the background.

I use Vim Fireplace, which gives me the ability to evaluate forms in a buffer by sending them to an nREPL instance. There's also a REPL available within Fireplace, but I find I only use it for simple commands like stopping a piece of music or printing a data structure.

Speaking to Aidy Lewis on Twitter today, I've come to realise that there may be two different models for REPL-driven development.

Aidy described a model where the REPL is ever-present in a split-window. This brings the REPL to the foreground, and makes it conveniently available for experimentation. I would describe this as a side-by-side model.

On the other hand, I treat the buffer itself as my REPL. I write and refine forms, evaluating them as I go. If I want to experiment, I do so by writing code in my buffer and either evolving it or discarding it. My navigation and interaction are as they would be in any other Vim session, punctuated by occasional re-evaluation of something I've changed. This seems to me more like a layered model, with my buffer on the surface and the REPL below.

The reason I value this mode of interaction is it makes me feel more like I'm directly interacting with my code. When I make a change and re-evaluate the form, I have the sense that I'm somehow touching the code. I don't have a mental separation between my code-as-text and the state of my REPL session. Rather they're two ways of perceiving the same thing.

Real live music

“Yes,” said Golg. “I have heard of those little scratches in the crust that you Topdwellers call mines. But that’s where you get dead gold, dead silver, dead gems. Down in Bism we have them alive and growing. There I’ll pick you bunches of rubies that you can eat and squeeze out a cupful of diamond juice. You won’t care much about fingering the cold, dead treasures of your shallow mines after you have tasted the live ones in Bism.”

- C. S. Lewis, The Silver Chair

I am fascinated by our collective fascination with live music. Why does it make a difference whether we access a piece of music through the thick dark air of a crowded pub or via a commercial recording and distribution process?

I question the mechanism, but I have no doubt as to the potency of its effect. I revel in live performance. I even listen to live albums - which I simultaneously find conceptually daft and utterly compelling.

My own pet theory is that liveness (life?) is a perception of the possibility of being otherwise. As each note is struck, plucked or sung, the audience knows that though the piece may be written a certain way, in a live rendition it ain't necessarily so. Any given note has the potential to be substituted, varied or flubbed.

But once a note has transformed from a musical intention into a perturbation of air and propagated through the room at (approximately) 340.29 metres per second, it drops down dead to the floor. The high note has been hit, or not. The high hat has been hit, or not. The blue note has been blown and the possibility of being otherwise has ceased.

Music-as-code offers a variation on this theme. If I, for example, describe my music with Clojure and Overtone, then I can render my music to my speakers. But I can also alter it at will. If I take care to directly represent the deep structure of my music in code, then I can easily make changes to instrumentation/tempo/swing that even editors and sequencers of binary sound files cannot.

I can bring the power of iteration, of version control, of collective review, of unit testing, of my combined past and present selves, to bear on a piece of music. The possibility of being otherwise is preserved.

Music created with Overtone isn't just live - in a sense it's immortal. What's more, we now have the perfect retort to the unkind critic - "Pull requests accepted".