Some theory
Not every use of code interaction on stage is an instance of live coding. When I first started working with SuperCollider a decade ago, I didn’t create GUIs. I started and stopped code on stage. I had comments in the code giving me instructions on how to do this. One piece instructed me to count to ten between evaluating code blocks. Another told me to take a deep breath.
Part of this was because I hadn’t yet learned how to invoke callback methods or use tasks. Some of it was to create a musical timing – a deep breath is not the same as a two second pause. This was undoubtedly using code interactions to make music. But in no sense were these programs examples of live coding. Once a block was started, there was no further intervention possible aside from halting executing or turning down a fader to slowly mute the output. These pieces were live realisations of generative music, which means they have virtually no interactivity once started whether by code or by other means.
There is not a bright line separating code based interfaces from live coding but instead a continuum between pieces like the ones I used to write and blank slate live coding. The more the interactivity of the code, the farther along this continuum something falls. Levels of interaction could be thought to include starting and stopping, changing parameters on the fly, and changing the logic or signal graph on the fly. Changing logic or signal graph would put one closer to blank slate coding than does just changing numbers on something while it plays.
This argument does imply a value judgement about authenticity, however, this is not my purpose. Different types of code interactions are better suited to different circumstance. A piece that is more live coded isn’t necessarily sonically or objectively better. However, this kind of value judgement is useful in applying the metaphor of live coding to other interactions.
I have been pondering for a while whether or not live synthesiser patching is an analogue form of live coding, a question first posed by Julian Rohrhuber (2011) on the live coding email list. On the one hand, the kind of analogue modules used for modular synthesisers were originally developed for analogue computers. The synthesiser itself is a general purpose tool for sound, although, obviously limited to whatever modules are available. (Thus putting it some place between a chainsaw and an idea. (Toplap 2010)) Both computer programs and live patches can quickly grow in complexity to there the performer can no longer comprehend exactly what’s happening. (Collins 2007)
On the other hand, there is no code. However, I’m not sure how much that matters. A PD or MAX patch created on the fly that crates a signal graph is clearly an example of live coding. If for some reason, the patching language had hard limits on what unit generators were available and in what quantity, this would still count. Therefore the transition from virtual to physical seems small. Instead of focussing on the code itself, then, let’s look at the metaphor.
Knob twirling is an example of changing numbers on the fly. Modular synthesisers do contain logic in the forms of gates and switches. This logic and the musical signal routing can be changed on the fly via re-patching. Therefore, a live patching performance that contained all of these elements would be an example of analogue live coding.
Gig Report
I very recently did some live patching in the Live Code Festival in Karlsruhe. Alas, this reasoning of what is or is not live coding did not become clear to me until I was reflecting back on my performance afterwards. This is the first time I was doing patching with any other goals in addition to making nice sounds, which meant I was pushing against places the sounds wanted to settle and I realised on stage I was inadequately prepared. There is both in live coding and live patching a problem of how to prepare for a show, something it has in common with forms of improvised or partially improvised music.
I had a conversation with Scott Wilson about how to practice improvised music that has an agenda. I should have spent the few days before the show building patches that use gates to control timbrel or graph changes. I should have also practised making graph changes in the middle of playing. Instead, I spent the days ahead wrestling with problems with Jack on Linux. I use SuperCollider to manage some panning and recording for me and was having tech problems with it. Mixing analogue and digital systems in this way exposes one to the greater inherent instability of computers. I could make my own stereo autopanner with some envelope followers, a comparator and a panner, so I’ll be looking into putting something together out of guitar pedals or seeing of there is an off-the-shelf solution available.
For this performance, I decided to colour code my cables, following the colour conventions of Sonology in the Hague, so that I would use black for audio, blue for control voltages and red for triggers. This was so users with synthesiser knowledge might be able to at least partly decode my patches. However, this caused a few problems. Normally, I play with cables around my neck and I’ve never before done anything live with cable colours. This time, every time I looked down, I only saw red cables but never actually wanted to use them. For the audience, I tried to make up for the difficulty of seeing a distant synth by using a web cam to project live images of it, but the colour was lost in the low resolution of the web cam. People who tried to just look at the synth directly would have trouble perceiving black cables on a black synth. If I do colour coding again, I need to swap the colours I use and not wear them around my neck. A better webcam might also help.
Aside from the low resolution, the web cam part was successful. I also set the program up so that if I pressed certain buttons on my midi device, slides would be displayed of modules. So when I patched an oscillator, I pushed the oscillator button on the midi control and a labelled picture of an oscillator appeared in the upper left corner. I didn’t always remember to push the buttons, but the audience appreciated the slides and I may extend this in future with more of my modules (I forgot to do the ring mod module) and also extend it to more combinations, so I would have a slide of two oscillators showing FM and one of three showing chaos.
Sonically, the patching seems to have been a success although it was not fun to do because I did have an agenda I was trying to push towards, but had not rehearsed adequately. I want to spend a lot of time now working this out and getting it right and doing another show, but that was it. My next presentation will be all SuperCollider and I need to work on that. I am thinking a lot, though about what I might do for the Other Minds festival next spring. I wonder if live patching would be adequately ambitious for such a high profile gig….
Citations
Collins, Nick. “Live Coding Practice,” 2007. The Proceedings of NIME 2007 [E-JOURNAL]
Available at: <http://www.nime.org/2007/proceedings.php> [Accessed 3 March 2012].
Rohrhuber, Julian. “[livecode] analogue live coding?” 19 February 2011. [Email to livecode list].
Available at: <http://lists.lurk.org/mailman/private/livecode/2011-February/001176.html>
[Accessed: 1 March 2012].
TopLap, “ManifestoDraft.” 14 November 2010. TopLap. [ONLINE] Available at:
<http://toplap.org/index.php/ManifestoDraft> [Accessed: 12 September 2011].
