Algorithms are Thoughts, Chainsaws are Tools from Stephen Ramsay on Vimeo.

In an extended video that begins with Radio City’s Rockettes and kettle drum players, Stephen Ramsay explains a litany of technology’s most elusive topics, in terms anyone could understand — no, really. I dare you to ask anyone to watch a few clips of this video, regardless of whether they’re regular readers of this site. Secrets such as why the programming language Lisp inspires religious devotion, or how someone in their right mind would ever consider programming onstage as a form of musical performance, represent the sort of geekery that would seem to be the domain of an elite. But in the dry deadpan of this Professor of English, those mysteries actually begin to dissolve.

I love the title: “Algorithms are Thoughts, Chainsaws are Tools.”

I doubt very seriously that live coding is the right performance medium for all computer musicians. (I expect I’ve occasionally made people wince with a couple of lines of code in a workshop example; I shudder to think of scripting in front of an audience. I’d probably be less disastrous at stand-up comedy.) But Ramsay reveals what live coding music is. It’s compositional improvisation, and code simply lays bare the workings of the compositional mind as that process unfolds. Not everyone will understand the precise meaning of what they see, but there’s an intuitive intimacy to the odd sight of watching someone type code. It’s honest; there’s no curtain between you and the wizard.

That should be a revelation about other computer music performance instruments, even the MPC. They, too, bring in elements that are as compositional as they are about performance (though the MPC has the unique power to be both at the same time). And sometimes, it’s seeing the naked skeleton of that process that allows audiences back into the performance.

The live-coding composer in question is Andrew Sorensen, who has live-coded an orchestra and does, indeed, also use samplers in the tradition of Akai. Whether you do it in front of an audience or not, you can try his gorgeous Impromptu music language, among other tools.

If you’re messing with code at all, even just to make an occasional bleep in Csound or picture in Processing, it’s worth watching Stephen’s videos. In fact, if you compose at all, it might be worth watching. (See also his reflections on writing, programming, and algorithm.) After all, even someone strumming out a tune on an acoustic guitar and scratching the results on paper is using some sorts of algorithms.

This video has been out for a few months, but I sometimes wonder how we got into the business with blogs of posting stories with expiration dates in the hours. It’s like buying milk in Manhattan.

Thanks to Philip Age for the tip.

  • Wow, what a great video by Stephen Ramsay! Thank you Peter for posting it.

  • neat.

    impromptu looks fun too!

  • Damon

    The live coding thing is clearly an amazing talent. I admire anyone who can do that, but it does seem pretty much a sophisticated parlor trick unless the music resulting can stand on its own.

    The question becomes, were you to hear the piece without observing the live coding performance, would it stand up, or is the quality of the piece augmented by the way in which it was composed?

    Is a decent painting painted by someone who paints blindfolded something I would rather see than an excellent painting by someone who paints in a conventional fashion?

    Cause unless the live coder can spin something up that I would enjoy listening to on my portable media player, I feel like music takes a back seat to the musician, which is a truly peculiar something.

    He's an amazing musician, but his songs are not really memorable outside the performance. That is like a brilliant comedian who tells run of the mill jokes. Is that oxymoronic?

    This is not to say live coding is something to be ignored, but where from ever in history have we asked this question? Does the musician matter more than the music?

    So I would hope the wiz bang geniuses who can genuinely "approach" the ability to live code can really make the music happen as well, for if not, it is hard not to view it as an amazing parlor trick mostly impressive to those who live in parlors. Like a log cutting competition among lumber jacks, pun not intended.

  • Stained ( is the one I love the most!
    Still I cannot learn livecoding. I wish I was 13 now. I was then learning on how to code commodore by listing programs…now my mind is not so open anymore. Regards and thanks for reminding me about Andrew.

  • Random Chance

    What he says about Lisp is wrong: Not everything is a list, there are atoms (symbols, numbers, strings, whatever the implementation allows you) and lists. Also this is not Lisp but it's scheme. The syntax of lisp is really a little more complex, because Lisp has macros and associated quoting mechanisms that are not present in Scheme. What he says about extending the language quoting Paul Graham (whose book about ANSI Common Lisp I can recommend to anyone who wants to learn Lisp) is actually more complex than just writing an operator (you could do that in other languages as well, and as lisp is prefix only and there are no infix or postfix operators this is also not really interesting to anyone who wants to know what sets Lisp apart). It's about letting the macro system write programs or code snippets for you (would be quite elegant for live coding, imagine for example a macro that expands to a case analysis like the one he shows (case (fmod beat 4) …)). This is covered in depth in the book he quotes "On Lisp". So, that was a glimpse of the kind of rant you get from Lisp people when you talk about "their" language. 😉

    That said, I'd like to advertise Nyquist (…) and Common Music ( which are music composition and DSP environments based on Common Lisp. The latter of which can be considered sort of the grand daddy of all the Lisp/Scheme based music coding environments. Of course, if you want to go way back you would need to deal with the offspring of the Music-N languages: CSound. Or if you like FORTH, have a look at HMSL. Oh, there are so many possibilites and so little time …

  • @Random Chance: I wonder what your feelings are on Clojure. I could imagine it still working for music and audio, and doesn't preclude keeping some DSP tasks in nativeland.

    I think I understand the point he was trying to make about Lisp.

  • poopoo

    I think it's phony. It is not about letting the audience in at all. It's about cultivating an stage presence of virtuosic technical wizardry. No one in the audience understands the code and that's why everyone marvels at the "magic". Worse still it's Lisp, a particularly archaic and obfuscated computer language.

    I can't help of think of all the computer hacking movies where they have fake GUI's and crazy keyboard mashing. The reason being that real computer hacking is kinda boring to watch and lacking "an intuitive intimacy".

  • Random Chance

    @Peter Kirn: Clojure is nice, it's a Lisp 1 by nature and the interface to Java land is pretty neat. There are also some nice datatype abstrations that work lazily by default (which is not very Lispy, but modern and pratical). Lazy datastructures particularly lend themselvers to generation of infinite sequences (say of pitches/duration pairs) according to some properties and just grabbing the number of elements you're interested in with minimal computational and memory overhead. I'm not aware of any live coding or music environment for Clojure but I haven't looked so there might very well be one. Or you can write one yourself free to choose your own abstractions.

    Apart from the implementation the most important thing when coding a Lisp dialect is the editor. Emacs works fine, everything else tends to feel limited and not very elegant. With all the keyboard commands of Emacs it's not unlike learning an instrument where you have to memorise and practise fingerings for some time before you can really play anything meaningful, but it's worth the effort.

    Concerning DSP in Java: It's doable and it's been done, see JMusic for example. The JVM implementations (with Hot Spot profiling and native code generation) are very good performance wise. So you could very well write the DSP primitives like filter algorithms, FFT stuff, etc. in Java while keeping everything else including all the compositional functions in Clojure.

  • @poopoo what an apt screen name 😉

    Imagine if we could nurture a culture of geeks reviewing and commenting on each others work like this on a regular basis? Christ that would be great!

  • Dano

    This is so great.

  • If nothing else, this video is telling me to take a second look into LISP for a viable computer music syntax. And that I really need to spend some serious time with impromptu.

  • <blockquote cite="Damon">The question becomes, were you to hear the piece without observing the live coding performance, would it stand up, or is the quality of the piece augmented by the way in which it was composed?

    Is there anything wrong with the quality of the piece being appreciated in a different way because it's live-coded? Seems analogous to, say, freestyle rapping.

  • @Daemon:
    I'll argue that "the proof (of the music's composition) is in the putting (of ear-buds into ears)" somewhat misses the value of how live-coding performances "must" explicate their compositional process and resources. One of the real satisfactions I've always gotten from seeing live-coding is how much I could learn from their naked example, regardless of how familiar I was with their tools or dialect.

    This virtue seems readily tied to live-coded-music's conventions of repetition and slow(ed) progressions.

    Compare a cooking show: it takes an hour for an expert cook (who has a backstage and a commercial-break-time-warp-oven) to walk out a recipe whose chemistry should take an amateur like me a fraction of the time to cook up at home. Few other improvisatory musics are so open to "teaching as you go."

    @ Poopoo…
    You're free to dislike something you don't understand, to knock the use of a vintage (tried and true) language like Lisp, or even dismiss it as "hip(ster) wizardry," but to suggest that this art is "phony" (as if it uses backing-tracks, auto-tune, or any such subterfuge) is just hugely inaccurate.

  • oh no, not live coding …

  • cubestar

    Is Zeb just instances of Zebra?

  • Ah cool. Andrew Sorensen did a live coding collaboration with Andrew Brown at an audiovisual gig I organised in Sydney during 2007. The performance started with two blank white screens and using nothing but QWERTY keyboards ended with a complex, interesting piece of music. Once you experienced the performance for a while you could see the timbres, rhythms, textures, etc in the Impromptu code as you listened. Definately worth checking out if you get a chance.

  • Joost

    Cool, gonna watch it.

  • Damon

    I would like to apologize. The music Mr. Sorensen produces in live code IS very listenable. Very much within a category of quality and good taste. I guess I was picking a philosophical snot road without acknowledging the destination.


  • Damon

    It is good to apologize when you have shot your mouth off, but probably better not to say anything that warrants an apology. 😛

  • Nowwwww, music is in trouble

    Rovi from Kinsta Music

  • Watching the video, it occurred to me that a it would be great if the audience could read up on the various functions being used in the performance in the program notes prior to the show. For example, defining what cosr does, what each of its parameters are for. It would certainly make the code that much more transparent.

    Is anyone doing this?

  • Random Chance

    @Jacob Joaquin: Although your idea has a certain charm, it would be impractical. It would be roughly equivalent to providing music theory, physics of instruments text and notes on playing all the instruments in an orchestra for the performance of a symphony. The Scheme report is some 50 pages long, adding all the specific functions that are in Impromtu and those that the performer has come up with would make for some very lengthy hand outs. The main problem is that for true live coding improvisation you do not no in a priori which functions will be used and there always be something missing which might just be the key to understanding some part of the program.

  • Adam M. Smith

    @Damon: Your view seems to be that the primary result of livecoding is the music (which is quite reasonable, given the topic of this blog). However, there are several other "results" that you can ask whether or not they stand alone.

    For me (as a livecoder as well), the primary result of the actual coding is the executing software process. The music produced is an incomplete view on what's really going on. In some of Sorensen's other videos, he demonstrates procedural graphics, and in his software (Impromptu) he provides the primitives for interaction with external devices and sensors. Graphics or even games could be the "result" that you look at, but each of these is just the byproduct of the process — the part where the creative efforts are focused.

    As a literate (in terms of software processes constructed on the fly) member of the audience, I can read between the textual code and the musical notes to see the process that Sorensen is spinning. (This relates to Poopoo's comments as well) There is something deep to see through the screen that is not perceivable through just the audio channel. While have a hard time to pointing to many really notable parts of music Sorensen produces, I could point (at the screen) to single out exciting moments where, say, a fade-out is accomplished through a quick sequence of parameter edits, new melodic progressions are unlocked by adding one missing transition to table of random possibilities, or how a bit of graphical animation actually foreshadows a musical development that you can see him working on in parallel.

    So, for me, whether the music can stand on its own is not a big issue. What Sorensen demonstrates is a fluency with the live manipulation of processes that is difficult to match. The various moves involve range from the very obvious (tweaking the volume or kicking off some temporal recursion) to the very subtle (such as changing the weight of a random selection which can't be perceived without listening carefully for an extended period).

    TL;DR: It comes down to literacy. The music is not the process in the same way that the shape of the ink spots is not the poem (concrete poetry notwithstanding).

  • Damon

    I think over time, as more of your average kids becomes enamored with computers and coding, the idea of live coding can only grow more popular, becoming less a niche gimmick and more an exotic progressive creative statement.

    The ideas of live code jazz style chat room jam bands would seem inevitable, or even live code battles, in the spirit of rap battling. Artists and players matched according to the level of their code knowledge, understanding, experience, or even musical taste.

    I guess we are seeing twitter style music exchanges as we speak, but that could very well be a mere forerunner of what is both possible and potentially revolutionary.

    It helps to take a breather and finish thinking something out before you speak.

  • @Random Chance: That's the extreme way of handling it, which I agree is very impractical. Though there are ways of tackling this issue. I've seen in program notes/guides/handouts at concerts that included bits of score that helped provide context to an audience. Live coding isn't so different that notes about the working mechanisms of the performance can't be included

    For example, many composers and/or improvisors have a repertoire in which they commonly pull from. Or as I usually refer to it, a bag of tricks. A live coder could provide information on their most used functions, or about a featured instrument or two. This alone could help enlighten an audience enough to transform a perform from that of magic into something more cerebral. If a live coder wanted the audience have available more than is allotted in a program, then they could provide a link; Many of us take the internet where ever we go, and do further research on the spot.

  • Random Chance

    @Jacob Joaquin: Ok, I was thinking along the same lines that you would probably just highlight some items from the artist's bag of tricks and that's all. But as for providing a URL: Live coding is just another form of a performance, so the artist has a right that the audience give him their undivided attention. It's at the lowest level a matter of courtesy and precludes members of the audience taking out their laptops or phones (those should be off in the first place unless you are a physician) to do research on the spot. Why not just go with it and take it as a musical experience rather than an exercise in code reading? If you know enough about programming you can follow the code without knowing exactly what each function does. In Lisp/Scheme it's very informative to just look at the shape of the code as created by the indentation and the parentheses. That's what programmers do. Most people I would guess lack the ability to precisely imagine the outcome (be it musical or graphical) of code and formulae anyway.

    Hmm, this reminds me: Live coding, coding for music is to music what procedural textures and geometry are to computer graphics. Maybe Create Digital Motion wants to explore this connections further someday?

  • Pingback: Slipmat » Lisp Revelation()

  • ash

    it may look magical to the layman, but to other devs u look like a tard. nobody wants to watch you type, live coding makes for a clumsy user interface.

  • You should check Music As Data ( The first live programming language in Clojure that rocks! Check the slideshare for the presentation at #dyncon!

  • learn coding

    Interesting article. This is really helpful for business. Thanks a lot for sharing your article with us.

  • learn coding

    Interesting article. This is really helpful for business. Thanks a lot for sharing your article with us.

  • learn coding

    Interesting article. This is really helpful for business. Thanks a lot for sharing your article with us.