Vexations

2020-11-06 music composition MSK 013 history

Erik Satie was a French composer who lived around the turn of the 20th Century and did a number of bizarre things, including the creation of a piece of music called Vexations which was not published during his lifetime but which has fascinated people subsequently. It's a single page of music, written with strange notation, containing an instruction that has been translated as "In order to play the theme 840 times in succession, it would be advisable to prepare oneself beforehand, and in the deepest silence, by serious immobilities." Although what that's really intended to mean is not clear, it's often interpreted as saying that the music on the page should be repeated 840 times, which makes a performance of the complete piece on the order of 24 hours long.

Wikipedia's article on Vexations goes into more detail on the history of this piece, performances and attempted performances of it, speculation on what Satie was trying to accomplish, and so on. In addition to being a test of skill and endurance for the performers, it is a test for the listeners. It's been called a "dangerous and evil" piece of music, and some have linked it to Satie's known interest in the occult. One pianist said he had to stop his performance when demonic creatures began crawling out of the sheet music. And as Sam Sweet writes in The New Yorker:

Consistent among both witnesses and performers are reports of the piece’s mystical effects. Pianists say there is something about Satie’s fiendish notation that makes the brief line impossible to memorize. Even after hundreds of repetitions, players are forced to sight-read from the beginning, as if learning for the first time. Witnesses have reported a similar effect. Listeners that subject themselves to the unnerving melody for several hours still find themselves incapable of humming it.

So, of course, I had to create a version of Vexations on my modular synthesizer.

Actually putting this together took several months. I kept running into technical hurdles, getting distracted with other projects, and so on. As you're no doubt aware, the last several months have been difficult for everyone. But here are some notes on the project.

The piece consists of a bass line (left hand on the piano) that gets repeated four times per page. There are right hand parts that get played over the second and fourth iterations per page; then the entire page is repeated 840 times (under the interpretation I'm using, which seems fairly standard). With up to two notes playing at once in the right hand part and one in the left, it seems this will require three-part polyphony.

I don't have enough synth hardware to really record three voices at once with the richness and complexity I'd like to give them, and I wasn't eager to try to record a single audio file that might be over 24 hours, in a single continuous take. I have enough trouble avoiding buffer overruns and such with my existing recording system on much shorter pieces. So my idea was to build a monophonic patch and record a different-length set of repetitions for each of the three parts, then play them all at once in such a way that they are constantly shifting relative to each other, until they all end simultaneously after the 840th repetition. Playing those three recordings at once with the proper synchronization could generate a full-length performance that would never identically repeat, because of the changing matching of each voice to the others. And the total amount of computer data would still be small enough that I could reasonably post it on my server for others to listen to without killing my or the listener's Internet bandwidth.

In order for that to work out mathematically, it is necessary for the numbers of repetitions in the three tracks to have their Least Common Multiple (LCM) equal to 840. The LCM of a set of natural numbers can be found by factoring them all into products of prime numbers and then multiplying together, for each prime, the highest power of that prime found in any of the inputs. For instance, the LCM of 12 and 10 is 60: 12=2²·3¹, 10=2¹·5¹, and so we need to include 2², 3¹, and 5¹ in the LCM, giving 60=2²·3¹·5¹.

To find three convenient-sized numbers with LCM equal to 840, I factored 840=2³·3¹·5¹·7¹ and then split that factorization into convenient chunks: 15=3¹·5¹, 21=3¹·7¹, 24=2³·3¹. I planned to record my three tracks to contain 15, 21, and 24 repetitions of the page. You can check for yourself that the smallest natural number that is simultaneously a multiple of 15, 21, and 24, really is 840.

I used Lilypond to create a clean copy of the score, and more importantly a MIDI file with the right number of repetitions for each track. Click on the image for the PDF. This is not exactly the same as published versions of the Satie composition; in particular, I normalized some of the usage of accidentals, added one that seems to have been omitted from some editions in error, added a time signature (13/4) to make it easier to navigate and a numerical tempo indication, and so on. But this sufficed for generating MIDI that could drive my synthesizer.

I chose the tempo of 30 quarter notes per minute because it sounds about right, and it makes the timing calculations relatively easy. At this rate each measure is 26 seconds, each page of four measures is 104 seconds, and the entire piece (840 pages) is 24 hours and 16 minutes.

I made a fairly straightforward subtractive patch using the Middle Path VCO as the main sound source, with the pulse outputs from the oscillators mixed and run into Leapfrog and Coiler filters, then through VCAs, and back into the Middle Path's shaping section (overriding the normalization). This way of patching creates a fair bit of timbre variation over the course of each note, because at the peaks of the attacks the waveshaper will be creating a lot of harmonics, then as the amplitude decreases the shaper is not adding much and we hear the limited spectrum from each filter.

This patch is also intended to create a lot of opportunities for manual intervention. I was concerned that some listeners might not be motivated to stream a piece of music over the Web for more than 24 hours, so I wanted the sound to change over time, to keep it interesting. Modulars are good for that, and I was able to automate it a little with LFOs, but I also did a lot of manual wiggling and a little bit of on-the-fly repatching throughout the time I was recording the three basic tracks. The diagram above should be taken as just the core of the patch; at some points I also had other patch cables run to do things like activate the Octave Switch's voltage control.

Of course, I had to go through several takes of trying to record this, either not liking the result or getting the files screwed up, and having to try again. I learned the hard way that my audio hardware cannot actually record at CD sampling rate (44.1kHz); if you ask for that, it will really record at DAT sampling rate (48kHz) and then it will convert the rates in software on the fly, which results in about a 0.1% timing error. That doesn't sound like much and for a piece only a few minutes long it won't be noticed, but with tracks of this length that will be repeated and must line up over a span of hours, it creates problems. That issue alone meant one batch of recordings had to be thrown out.

Given the three recordings, it was also a challenge figuring out how to line them up and play them, with synchronization that will work properly over the entire length of the piece. I eventually came up with some Javascript code that at least works well in my own installation of Firefox. It starts the three tracks (in hidden HTML5 "audio" elements) and then runs a loop that checks, once per second, where the tracks currently are in their running time as compared to the time that has elapsed since the start of the performance, and adjusts them as necessary.

Press the button to start listening, and be sure to comment describing your experiences if you actually make it all the way to the end. Management not responsible for supernatural or mental-health effects.

0:00:00

EDIT: As might be predicted, after posting that I've encountered new problems. In my browser it seems to stop working after about nine minutes, which is especially peculiar given that that's less than the lengths of any of the component tracks. This didn't show up in my local-browser testing. I'll do some more debugging...

◀ PREV PCB design mistakes || December 2020 updates: shipping, Twitch NEXT ▶