September 10, 2004
Performance programming
Alex McLean recently published Hacking Perl in Nightclubs at perl.com. Alex is a musician who performs electronic music by hacking music generation perl code live in a front of the audience. He’s also one of the founders, along with Nick Collins, of the Temporary Organisation for the Promotion of Live Algorithm Programming.
Why does Alex do perl programming performances? He says:
However, when running my Perl scripts during a performance I grew to feel as if I wasn’t really performing — I was running software I’d written earlier, so to some extent the performance was pre-prepared. I could tweak parameters and so on, but the underlying structure was dictated by my software. So what’s the alternative?
Over the last couple of months, I’ve moved toward writing software live, in front of an audience. If a programmer is onstage, then they should program!
He’s developed a perl infrastructure and a custom programming environment (his program editor doesn’t have a save command) that allows him to generate music through live code hacking. One of the interesting features of his environment is that the running code can modify it’s visible source code in the editor. He uses this feature to do things like have the program dynamically add and change comments in the code that describe what the program is currently doing; he has dynamic bi-directional communication with his running music generation processes at the source-code level.
Similar to the dogme manifesto, the TOPLAP Manifesto describes the conditions for live programming performances that qualify for the TOPLAP seal of approval. A couple of my favorite manifesto points: “Programs are instruments that can change themselves”, and “Code should be seen as well as heard, underlying algorithms viewed as well as their visual outcome.”
Programming performances can be seen as part of the contemporary software art movement (and indeed, TOPLAP participated in the Readme software art festival) as well as a current within the tradition of constrained programming, other examples being the Demoscene (1 2), competitions such as 5k (all program entries in 5K must be 5K or less in size), the modern classics game scene (people writing new games for historic consoles – Nick blogged about this recently) and generally anyone trying to pull off interesting programming feats on old, highly constrained hardware (check out the 1998 Manchester Baby programming competition)
September 10th, 2004 at 9:20 pm
This is really cool. Thanks for the links.
September 11th, 2004 at 10:18 pm
I like the programming-on-the-fly aesthetic for live computer music, but I can’t help but think using Perl is a bit odd. When you have a hammer…
Not that it’s perfect, but ChucK, a PhD thesis of a Princeton student, seems a lot better choice. It’s still very imperative and C-like, but at least it’s a little bit more suited to the domain.
September 12th, 2004 at 8:42 am
ChucK is interesting, and may indeed be more specifically tuned (as it were) to the task, but it strikes me that Perl has a certain … familiar purity as an interpreted scripting language that makes it especially suited to live performance. Since real-time modification is the key to live software performance art, it seems inexorably tied to interpreted, rather than compiled languages.
Since the audience is usually viewing the performance not just by ear but also by eye — looking at the actual code — using Perl may facilitate broader audience participation. I wonder if it may be more “classical” if you will? To analogize, I can appreciate the music that comes from a handcrafted, one-of-a-kind electric, nose-operated bagpipe, but I can perhaps I can’t readily situate such a performance relative to other musical performance. A bassoon or a violin is different.
There are myriad interpreters now, even for commonly-known, normally compiled languages, but Perl has a special place as a very popular scripting language and one that has a special propensity for breaking from its “intended” application. In my mind, it makes the use of Perl in this context somewhat poetic.
September 18th, 2004 at 3:03 am
Well, interpreted vs. compiled is really an academic distinction these days. If it’s a compiled language, but modules can be injected in real-time, and compilation can be done in perceptibly negligible time, it’s essentially interpreted from an audience’s point of view.
My main like of ChucK though is actually the visible aesthetic you mentioned. On-the-fly programming in Perl has too much non-expressive code for my tastes, mucking with array indices and loops and whatnot, while ChucK code tends to more directly be expressive. There’s also the issue of cognitive load: can one actually create complex real-time music in Perl without memorizing a significant part of one’s performance ahead of time? Perhaps, but it seems difficult.