What aspects of your "live coding" sets do you prepare in advance vs. code on the fly?

Performing
23

I enjoy live coding from a blank page. I do not currently use prepared text that I evaluate during a performance, but I do have a premade library of functions and instruments I use when doing rhythmic music that I consider a part of the system rather than the music being live coded. I do use a couple of keyboard shortcuts that insert snippets of code I will then modify to speed up the coding, but the code entered doesn’t have any pre-determined musical meaning (i.e., it’s akin to “insert a pattern generator” rather than “insert a walking bassline” or “insert glitch drum beat”).

It is personally satisfying from the creative perspective to start with the blank page and just go and see what happens. A lot of what I practice does come up during performance but making the musical decisions during runtime, even if they’re ones I’ve made before, is a part of the joy of the practice for me. (Though, I don’t know if it’s always great from the listener perspective when a coding or musical mistake takes a while to sort out and the audience has to listen to things go on a while!)

One thing that has been coming up often in recent practice sessions has been developing an initial sound generation instrument from scratch but then copying/pasting/modifying it to build up textures of sonic processes. It’s a new development for me and I do not know if it is easy to follow for either programmers or non-programmers as there’s suddenly a lot of text being shown on the screen. It’s not quite everything typed from scratch but I suppose it still shows the musical decisions being made on screen.

That said, while my own practice thus far has been starting from scratch, I don’t have issues with using pre-written code as a basis for performance and I have been considering exploring it for my own work. I have seen performances where everything is pre-conceived and coded, where the performer really is just evaluating the code like an instrumentalist performs a composed score. That kind of approach doesn’t quite appeal to me for my own work, but I don’t have issues with it if the performance ends up in a satisfying result. (Perhaps the potential for variances in interpretation aren’t the same as with instrumental composition/performance though.) In my recent practice sessions, starting from scratch each time, I found there’s a lot of common code that I end up retyping at the start of sessions that is just plumbing work and not musically interesting either as a creator or listener. This code also isn’t something that can be abstracted away into library functions or system code. It’s scenarios like these where I think a starting template of code that I modify at runtime might lead to a better experience for me both as a performer and as a listener.

4 Likes
24

This is a great topic and one that I’ve thought about a lot. I really appreciate the opportunity to read all of your opinions about it, from different perspectives and backgrounds.

I recently published a blog post about this very topic on TOPLAP, approaching it from the perspective of a session musician/instrumentalist:

Oscar

1 Like
25

All my live coding performances have been based on preconceived musical ideas and structures. I don’t let anyone hear anything I haven’t rehearsed for hours and hours. I have no confidence in my improvisational skills (past saving my set from a ‘mistake’ here, a typo there) when historically it takes me days or even weeks to create something I feel is complete. Just the way I am. I’m an album kinda guy.

However, my live coding practice in itself has evolved since my first performance in Brighton almost five years ago. I thought it had to be from scratch to be legit, so I spent weeks obsessively practicing and memorising my set, starting over immediately if I made an error, in an absurd iron man challenge to myself. It turned out OK in the end, but it was insanely stressful on stage, even after dousing my fears with multibeer and chain-smoking, and I decided after recovering from the next day’s hangover that it wasn’t a sustainable approach for me personally.

In subsequent performances I started using a two-pane approach with my ‘scratch pad’ on the left and some notes on the right, and I deliberately obfuscated my notes so I couldn’t just copy-paste and execute them as-was. This was a healthier balance for me, but still necessitated a lot of typing and I felt I wasn’t moving as fast as I needed to.

I started letting myself copy-paste chunks of prepared code into the scratch pad, but then I wound up with extremely long notes and had to scroll constantly and move back and forth a lot, distracting from what was actually going on musically. Plus the work to maintain and coordinate my notes was staggering. I was starting to mix different pieces a lot more, reusing older work, but various habits (in particular, aliasing channels within each project) made it harder to resolve conflicts from one piece to the next.

Eventually @yaxu made me aware of the yasnippet plugin for emacs, and I completely redesigned my flow to remove channel aliases and make it easier to mix and match individual parts of different pieces. Additionally, using expanding snippets instead of copy-pasting stuff meant I could use a single pane again and keep visual focus on the actual events of my set. My last two or three performances made heavy use of yasnippet, and they are the ones that required the least prep (past the initial setup work, anyway) and that I’m happiest with when I play them back now, although curiously I’m most nostalgic for my first ever performance. I think the challenge made it more exciting somehow.

I think spending so much time over the years on my process distracted me from actually coming up with fully new ideas. Somewhere along the way I became too reliant on my system of remixing myself and forgot how to do what I set out to do in the first place when I discovered Tidal. My ambitions kept growing, but I spent too much time going in circles instead of continuing to innovate, at least in my own estimation. I turned enterprise, and I’ve struggled for some time to unlearn these habits.

Lost my train of thought there… I think my point is that I have yet to figure out a balance that works for me. Too much from-scratch, I sweat buckets on stage and get insanely drunk to calm down. Too much prep, my imagination goes. Wahey!

1 Like
26

Super delayed response, sorry (it took me this long to figure out how to quote posts!) but I haven’t seen anyone else doing it yet!

Since I started live-coding, I’ve had the lyrics of my songs mixed in with the code so people can read along as I go through it; that was an idea I got from a gig I played waaaaay back when I was doing hardware-only stuff (it was one of these http://theawkwardsilences.com/outsider-pop-nights) where all the songs were subtitled, and I loved it so much both as a performer and an audience member that I figured now I have a screen behind me all the time I might as well have my lyrics be permanently captioned. So when I was thinking about how to make the actions more comprehensible I guess it seemed a fairly natural fit to ‘caption’ the stuff I’m doing as well as the stuff I’m singing.

So initially I’d only thought about wider context in a non-programming, ‘subtitles’ sense. But THEN I was playing the toplap15 show I logged on to talk.lurk afterwards and someone had compared what I was doing to ‘emacs-style literate programming’. I had absolutely no idea what that referred to so went away and looked it up and it pretty much is what I’m trying to do live, I just didn’t know it was a formalised style of coding, and (as a bad but learning programmer whose learning style is very very very verbally-focused) I absolutely love it and selfishly wish everyone did it. Whether anyone else is applying it to live-coding, though, I have no idea!

1 Like
27

I haven’t played live-coded sets yet, but played + 150 live-gigs years ago, so I’m - at first anyway - planning to do the same I used to do back then : live remixing of pre-written material. With much more freedom than I’ve ever had though. The studio is where I experiment from a blank slate, the stage is where we share the fun :wink:

I used to mangle my own audio (either with Live + a bunch of stems of my tunes and MIDI controllers, or using a Monome 40h/256 and mlr), as my studio session were impossible to run real-time on stage. I could run some sort of auto-pilot mode though, which allowed me to have tons of fun jamming and engaging with the crowd.

Now I’m using the very same set-up in the studio and (soon) live (which was impossible for me before), so I can rewrite a tune on the fly within a few commands : that’s so bloody amazing ;D

Computers being much faster than a decade ago, I can run all sorts of demanding synthesis / processing real-time too, so I feel like having a score and being free to instantly (re)interprete it in numerous ways ?

I don’t know if you guys have listened to Autechre’s Æ LIVE recordings ? Many similar themes in each live set, yet with fantastic variations from one gig to another (the tracks being stunning to boot with). That’s pretty much what I aim for in a not too distant future. By the way I remember reading a recent itw in which they mentioned how they’ve been live-patching / live-coding for years, that might explain the flexibility here.

Even if most of the music is pre-composed, there’s still room for challenge and risk, don’t you guys think ? Still pretty different from “simple” playback :wink:

Full live improv must be incredibly exciting and liberating, but I’m afraid I’m currently too much of a noob yet to embrace that.

Fantastic topic by the way !

28

Same here, i performed as an instrumentalist (and sometimes electronic musician) in bands and stuff before performing as a live coder.

My approach to instrumental music was fairly improvisational, and the one thing thing that I never liked that once you got a song tight enough to play it on stage you’re already bored by it, and i kinda tried never to play a song the same way twice (which doesn’t work too well in a song-oriented band).

Thus, when I first came in contact with live coding, my approach was kinda naive in some sense, and starting with a blank screen nearly seemed synonymous with live coding for me.

When i saw live coders just tweaking some parameters i was a bit disappointed and wondering why they are not just using controllers.

Later on I started doing a couple of performances with prepared code, but got bored with it fairly quickly, and as my system got more concise and stable, and i gained more experience with it, i started goind back to a blank screen approach.

So what do i prepare? Well, nowadays mostly my system. I guess i never performed recently without having new feature or two.

It’s not even that much of a challenge anymore, even though of course there’s the danger to repeat yourself. But I frequently get compliments on my eclecticism, people say that seeing me play is always a surprise (mostly pleasant. i hope), so i guess i didn’t fall into that trap yet.

29

Graham Dunning annotates his code and when we collaborated I did too (we made a conscious decision to do that). It helped me as a performer manage the code and we got some positive feedback on it too so I’m going to try to incorporate that into my solo sets too (if I remember) :slight_smile:

More generally I usually start with a blank screen (or maybe my ‘first line’) except for when I’m doing midi stuff as I can’t be bothered to type out all the midi business each time so I start with a kinda ‘midi template’ that I’ve pre-written. So most of my code is ‘typed live’.

In terms of preparation I have pre-prepared samples and I’ll probably have figured out a palette of sounds. Then I have little tricks that I always enjoy and will usually do at some point, but maybe they don’t always sound the same (e.g. maybe it’s a combination of functions but I would use them with different sounds). Or I have certain samples that I like to use in a particular way. But often I’ll just try random stuff out and it doesn’t always sound good but I think that’s the most fun approach for me. (and tbh I’m still astounded that anyone even likes the music I make!)

If the show is ‘higher pressure’ (lots of factors influence that for me - am I early or late in the bill, is it a big audience, is it a high profile show, is it a dance party, am I in awe of the promoter or other artists etc) then I’ll probably have more set ‘ideas’ that I’ll use. Or if I start to panic I might open some code from a practice and copy that in. this is less fun for me but results in what I think of as a more audience friendly or palatable performance. I don’t really know why I do this as I’m usually less happy with my performance but I think it probably comes down to anxiety levels at the end of the day. I’m a nervous performer at the best of times.

The goal for me is to have a lot of ‘ideas’ from practice so that I can feel confident in a very improvised performance. Those ideas are not necessarily even a set thing, they could be an aesthetic (e.g. “noisy”), or based around a certain sample that I like, or combining functions in a particular way. I feel as though I’m working towards a place where I have a distinct ‘heavy lifting’ sound, but that within that I can play around with loads of different ideas. That’s really the ideal for me.

Then when I play in TYPE (with @ryan & two other pals) it’s much more a free for all as he says in this thread. We plan out maybe some rough aesthetics (e.g. 80s, dancey, noisy, rhythmic etc) then just go for it. With four brains and eight hands between us we can get a lot of code written and try out a lot of ideas, which means each of us has a bit more time and space for thinking and experimentation than when we play solo. Plus you vibe off the other players and have more space to listen, so it feels like a super free way of making music :smiley: And of course you can’t have too many pre-prepared ideas cause someone will just come along and re-write your code ha!

30

A stray thought… Sometimes I have to play without good monitoring, so I can’t hear my sounds very well, making improvisation impossible. I end up having to fall back on pre-prepared stuff and set pieces then, but it’s horrible because I can’t hear most of it, even if the audience can. In this situation DJing feels very attractive.
I was just wondering whether this is part of the reason why I don’t like using pre-prepared code too much - because I associated it with bad sound / bad sound engineering…

31

That’s why I think I will use headphones in the future, hard to handle improvisation otherwise, especially at low dynamics

32

I don’t think enough people noticed the distinction in what you said with pre-prepared vs having written the entire livecoding system with specific goals in mind. If someone has built in a number of functions and musical/functional concepts that they expect to perform with into the system itself, then what part is the improvisational part? I’ve performed with coding recursive functions from a blank screen, and it takes time to write that sort of structure into a performance. I think livecoders can look a little deeper into their repertoires and think about what a “blank screen” really means. Because the idea of “coding from scratch” is a bit disingenuous.

For those people who are a bit dyslexic, being on stage and having to correctly type things in the correct order is quite difficult. Also underrated in difficulty is trying to type whilst your laptop is shaking from sub-bass on a flimsy table! I prepare a lot of things in case I just can’t type properly. And also if my memory glitches a bit.

I don’t perform a ton, but when I do I practice a lot and leave some cut/paste musical phrases and harmonies lying around. It takes too long to type them, and the interesting thing is playing with them in a live setting, not coding an array in front of people. I could, if I was a “blank screen purist”, just stash the notes in a variable and run it in startup so I started with a blank screen but I like having the audience see the work underneath the performance as I scroll by it at the start. Whether that’s successful or not is another story…

33

I will disagree and guess that many of us are thinking about these issues carefully, and are well aware of the various levels of abstraction at play. And certainly almost everyone in this thread has been really careful to not prescribe their approach as canonical / correct; these are individual preferences being expressed.

34

The thing is you can have your structure written and still improvise if you allow for chaos. in your program. Having pre-written scripts is not exactly the same as evaluating a big chunk of code, fully automated that will not be intervened in any way. So even with pre-written functions or even keywords or controllers you still can keep the level of volatility you are valuing as authentic I think improvisation comes from the way you operate a tool or system and not by the system itself. You can also memorize a program and type it by heart , that is not more authentic or improvised than tweaking , deleting, modifying existing code. As @charlieroberts I am also non-canolical and I believe each develop his/her own values, methods and performing universe.

1 Like
35

Maybe people think about it, but I’ve received criticism before for being a “code DJ” (not my words, not meant to be a compliment) and I’m sensitive to the idea that it’s more “pure” to start with a blank screen. As @anny wrote, “I thought it had to be from scratch to be legit.” Its a theatrical flourish that has a built in narrative and ultra-minimalist aesthetic to it, and that’s not my bag. That’s all I’m stating here, no judgement, I don’t think there’s a conspiracy but there is a group-think that arises from some people knowing what’s under the hood and others needing or wanting to make that more explicit. There is no “pure” form of livecoding: it’s all abstractions all the way down, and some people have spent more time writing them than others. Great! More power to them, it’s a real dedication to their craft.

I can code from a blank screen pretty well, but I personally find it repetitive and… stressful. Anti-improvisational. It feels like using an instrument that I need to bolt together first before I can play a sound. It means focusing more on typing skills than on compositional/improvisational ones. I think there’s often something to be said for making small changes and see/hearing results. That’s all, no offense meant.

36

As I already wrote, for the first year or so I kinda shared that sentiment … I wonder why that seems to be such an obvious first assessment of live coding ?

As my horizon regarding live coding expanded over time, it changed a lot. I’ve seen a lot of performances in either category that were amazing.

To me, both ways seem repetitive, but I prefer the “blank-screen-repetitiveness” over the “prepared-code-repetitiveness” because the former one feels less like “practicing a song” to me.

37

Well… it’s all repeating algorithms in the end, innit? :wink:

1 Like
38

I disagree with all of this sentence except the “not my bag” part, but I don’t think the online format is doing us any favors here… looking forward to to hashing it out more over a beer someday :slight_smile:

1 Like
39

there’s always ICLC :wink:

40

Because free improv from scratch is how it’s generally explained I guess… Its quite hard to explain live coding, and so you find yourself explaining the most extreme case to make the point that it is an open ended practice.

41

This is why I always have headphones! I always associate bad sound with a bad performing experience, so I think you maybe have a point here!!!

42
4 Likes