Andrew Sorensen is an Australian musician and programmer, author of the Impromptu live coding environment as well as a live coding musician of note. I recently caught up with his latest work, documented as screencasts on his site. In A Study in Keith Sorensen builds a Keith Jarrett machine that juxtaposes two linked layers of performance - qwerty and (phantom) piano keyboard. Stained (below) is a striking twist on the "transparent" aesthetics of live coding, as Sorensen uses Impromptu to draw in, and manipulate, the code window, hooking the graphics into the musical algorithms. These works demonstrate (for me at least) how live coding can be honed to a fine point, as a performance form. They're improvised, but also controlled and restrained; they work well as music, but clearly the real performance here is also in the developing code structures. It's in the combination of those two structural levels - the emotional impact of tonal music and the abstract, formal domain of code - that these works are really strong. In this conversation Sorensen touches on the live coding scene, performance, craft and virtuosity, code as score, coding without computers and algorithm as thought
MW: I saw that you went to the LOSS livecode festival - how was that? What's that scene like?
AS: Actually LOSS was fantastic. I was a little concerned at first because the number of attendees was very low (20 ish) but this ended up being one of its real charms. It was a really on the ball crowd and so the general level of conversation during the 3 days was really excellent. It was great to see everyone perform, particularly SLUB, as it was Alex Mclean’s “Hacking Perl in Nightclubs” paper that initially caught my interest. I would have enjoyed seeing a few more from-scratch live coding performances. From memory there were only 3 of them - Fredrik Olofsson, Graham Coleman and myself. Most of the other performances used pre-programmed material - which I should emphasise is still perfectly valid but I was hoping to see more from-scratch work. I should also mention that Ross Bencina and Robert Atwood both performed from-scratch live patching works. (Ross in Audiomulch and Robert in Pd).
One of the great things about that scene though is the general competency, both artistic and technical. It’s hard to find people competent in both areas. I think one of the things that emphasises this for me is that most of these guys build their own environments. And these are good environments displaying strong technical competency. Yet almost none of these guys are working as professional programmers, choosing instead to concentrate on artistic and academic projects when they could all be out earning squillions as programmers. This focus on the creative and dynamic use of computation really shined through for me at LOSS. Of course the downside is that live coders are all broke... Of course there is a history of broke hackers but that's another story.
MW: I'm attracted to live coding for the same reason - a sense that these artists are something like virtuosi in their field. But then I'm very interested in what that means, to be a virtuoso live coder - and whether it means something different in a small, expert gathering such as LOSS, to what it might mean in a different context.
Good question. I think one thing worth thinking about though is that there are a lot of people in the world with some programming experience these days. Most of the time this is at a pretty basic level, some VB scripting in Excel for example but still the number is growing rapidly, especially with younger generations. I guess in short the number of people who have a basic conception of what's going on (even if they don't understand any of the specifics) is quite high and is growing rapidly. How many people at an Australian Chamber Orchestra concert have ever played the violin - still this doesn't stop them from being mightily impressed by Richard Tognetti. In this sense of course small expert gatherings are always going to be ... well ... small.
Another interesting aspect is the high level of domain knowledge required. Just as music domain experts may struggle with the code’s syntax, good programmers can become just as lost trying to understand the semantics of a musical live coding performance. A musically literate crowd can often pick up on things even though they have no programming experience. If I type for example (random ‘(I ii IV V vi)) a musical audience will automatically pick up on the chord association that a programmer may not. Of course this all comes back to the types of symbolism that you employ.
MW: You also mention that many of these artists (including yourself) have made their own coding environments: how important is that? It's an interesting contrast with other genres - imagine if the first task for every young new media artist or computer musician was to write their own authoring tool from scratch! On the other hand for many computer artists of an earlier generation, this was an everyday reality.
Yeah, this is a really interesting question, and as you say certainly a generation ago this was almost always the case. I should say that when I talk about environment I don't necessarily mean a whole environment like Impromptu. Most of the time the environments I'm talking about are built on top of something else (well of course everything is built on top of something else but you know what I mean). Many of the "environments" that were at LOSS were built in Supercollider for example. So I don't think I'm advocating building everything yourself. The most important thing is spending the time to know your environment well. For example, one Impromptu user has built his own bindings to CSound. Not something I would want to do in a million years but he loves it and he's really productive with it so there's an example of an environment built on an environment. And the end result is that his live coding looks very different from mine even though we both use Impromptu.
It's an issue of fluency for me. Of course I'm a big advocate of craft so you'd expect me to say that!
MW: LOSS billed you as "one of the masters of from-scratch coding." I used to do a lot of sound work using only live-sampled material, which was a challenge - but live coding from scratch is something else. What's your interest in this approach?
Well, I guess there are a few things here. The first is that I think from scratch is more flexible. You aren't as emotionally constrained as you are if you're working from prewritten code. By this I mean that if you have the code in front of you you're just not as likely to explore. Of course lots of people will say that everything is an abstraction and that you never really start from scratch, which is of course true, but I think this misses the point. The blank page has a unique and mystical quality of endless possibilities.
Secondly I think it makes the ideas more obvious to the audience. Strange as it may seem I think that this is even more important for a non-literate audience. They seem to understand that code is being constructed for them in real-time. If you start with a page full of code they're less sure what's going on. For me the code is an important ingredient of the performance. As you have said before - how it is done matters.
Thirdly, it's more fun because (a) it feels more spontaneous and hopefully the audience realizes that they're hearing something created in the moment, and (b) it's more dangerous. One of the things I love about live coding is the adrenaline rush! You kind of forget that when you stop performing. I think audiences also understand and enjoy the risk of failure.
Fourth, I honestly think the music can be better if you aren't too constrained. It's good to be as adaptable as possible - although this is a constant challenge.
MW: The idea of being more or less "emotionally constrained" when coding is striking. We don't tend to think of coding as an emotional experience - can you elaborate?
I was really just suggesting that people will use pre-written code if it's there. They are less likely to forge a new path if one is sitting right in front of them. It is this kind of emotional constraint that I was getting at.
Having said that, of course coding can be an emotional experience - it all depends on what you are coding. I don't get emotionally engaged when writing out a shopping list but I can well imagine that novelists become emotionally engaged when writing. I'm sure people have no difficulty imagining that coding can be frustrating when things are going badly and exhilarating when a difficult problem is overcome. Of course producing something aesthetic just adds to the range of emotional responses that coding can elicit (often accompanied by frustration and exhilaration). And of course there’s the music. If that’s not giving you some kind of emotional response then you’re just not working hard enough!
MW: I found your screencasts quite affecting, which surprised me - especially when in A Study for Keith (above), for example, there's nothing but code for the first minute or so. The music is emotive in its harmonic language but it wouldn't have the same impact without the code. There's a contrast in fact between the explicit, formal language of the code and the lyricism of the music. It's a sort of pathos that works because clearly these two things are tightly linked - the formal machinery of the code is generating the music.
Yes, this is true, but I also think it's worth remembering that this is not a new phenomenon. Composers have been using symbol systems to describe musical processes for a long time now. Of course programming languages have given us far more symbolic power but this does not deny the fact that composers have been working abstractly for a long time. I very much think of the program code as a "score", albeit a dynamic one. Of course this is one of the things that makes live coding fascinating - the audience actually gets to see the formal machinery that has really always been there.
Where live coding differs from the "score" metaphor is that it is also a performance practice. So there are two elements at work in the program code. Firstly the symbolic manipulation described above but secondly performative control. So in the context of an 18th century classical paradigm it is not enough to describe just the harmonic, rhythmic and melodic information, it is also necessary to describe the performance information (i.e. timbral/ gestural information over time). I think there is a very interesting mix of event based and signal based work in live coding which I think sets it apart as a platform for improvisation.
MW: The TOPLAP Manifesto is very interesting here. Its first line is "Give us access to the performer's mind, to the whole human instrument." Along similar lines it states that "Algorithms are thoughts." Do you agree?
This is a tough question. Is mathematics a creation of pure human thought, or does it have some platonic existence? Algorithms raise similar questions. But maybe this isn't the important question. Algorithms, whatever their true nature, can communicate a useful subset of thoughts - they are a shared vocabulary that we can use to communicate ideas. In this sense live coders communicate their ideas rather than share their thoughts.
MW: Though this is a distinct kind of idea; it's an idea for a procedure, an idea for action - and we perceive both the formal notation of the idea, and its action. And what's more we perceive the relation between those things - this is the program / process semantics idea that you pointed me to earlier.
Yes, exactly.
MW: I notice that Nick Collins has been exploring live coding without a computer - emphasising the idea that the "work" in live coding is an algorithm or procedure that can be implemented in different ways. What do you think of this move?
Does computation require a computer? Of course the answer to this is no it doesn’t. Is live coding about computation? I think the answer here is yes, although this is a bit weak given that we still don’t have any strong idea about exactly what computation is. So in short Nick's work is perfectly valid. However, my slightly longer response would be that I’m not sure of the point in doing live coding without the symbolic power of the computer/ programming language. I think my problem with non-formal live coding - live coding with humans for example - is that the process semantics become incredibly vague. Now of course this ambiguousness is something that some people love, but in terms of a new paradigm I’m not sure what is really different here from the conceptual art movement of the 60s? In contrast, I think the program and process semantics of formal live coding are something new. Maybe this all just comes back to my craft focus again and a bias for the art object. In my work I enjoy crafting the result in the task domain.
Something that does interest me though is working with acoustic performers. I've been thinking for some time about doing a live coding performance where Impromptu output standard musical notation to four LCD displays for a string quartet to perform from. The displays would update one bar at a time giving the musicians a small amount of look ahead. I’m also very interested in working with acoustic musicians in collaborative improvisational settings.
MW: In Stained you begin drawing graphics into the code window; I really enjoy the moment where we see you prepare the code for the graphics, only to have those forms overlay the code itself. This is a direct illustration of your point about code as both performance and notation - it literally flattens those two layers into the same visual space. Where is this visual side of your work heading?
AS : Well, I should start by saying that all my history is bound up in musical, not visual work - so I'm a complete visual novice. I think the easiest answer to your question is to say that I'm exploring the space at the moment. Just enjoying playing.
Read More...
Summary only...
