Notes and ideas about the challenge of live coding


#1

Hi,

I would like to discuss some ideas about live coding. I am especially interested in how to solve the challenge to express musical ideas live in front of an audience and to entertain the listeners while coding music live. What I do like most about it, is the challenge of improvisation, which naturally involves that you can not (and in my view also don’t want to) fully control the outcome. Nevertheless you will have to know your stuff, because IMHO that’s always the base for improvisation.

Sam has already given some important and experienced thoughts about how to live code (see the Appendix of the tutorial), not to mention his many videos which prove that he is very proficient in the matter. Surely practice is paramount; we probably can agree about that. In this respect Sonic Pi is like learning the piano. I am interested in sharing my ideas and to hear from others about what and how to do that as well as general ideas about how you approach live coding.

So as a starter let me just sketch out 3 ideas I have come up with to practice and to tackle the challenge of live coding to hopefully get the discussion going:

Coding time, musical time, complexity

One of my strategies is to find solutions how to achieve expandable complexity in sound and musical structure with as little code as possible. I just don’t have the time to write a full-fledged score while typing in single characters. On the other hand I might want to get something engaging going without needing 10 minutes of silent coding or ever repeating sound. So how to get things going, to prepare and activate musical developement and possibly create an interesting progression of musical ideas whithout just using prepared samples or precoded snippets? Which obviously is perfectly viable solution (but I do not want it to be my only choice). One possible solution is that I try to work with musically coded ideas which have the potential to change and develope sound/structure/harmony and other musical ingredients whith only a few coded parameters. To show an example of what I mean:

use_bpm 120
live_loop :noise_to_music, sync: :bar do
  use_synth :noise
  use_synth_defaults attack: 4, sustain: 12, release: 4 # de/increase from 1 to whatever to go from single notes to a sound plane
  4.times do
    with_fx :rbpf, centre: (scale(:c4, :minor_pentatonic, num_octaves: 3).choose), res: 0.95 do # change scale for melody/harmony and resonance for noise to notes
      with_fx :slicer, phase: [0.35, 0.65, 0.85].choose do
        with_fx :slicer, phase: 0.25, pulse_width: 0.8, smooth: 0.1, invert_wave: 1 do # interleave slicer to create rhythmic complexity
          play :c1, amp: 1
        end
      end
    end
    sleep 1
  end
end

There are obviously unlimited ways to implement this idea: Have one live loop with multiple (but not totally random) ways to develope musical parameters.

Code memorisation and/or invention

One exercise I came up with is 1. to work out some ideas (more precisely: live_loops), combine these into a track and then 2. write it down as a shorthand. I then try to recreate the track using the shorthand. The idea behind it: a) to learn language constructs, to develope a sense of what code will sound what like, to slowly build up a vocabulary of sounding code snippets which - and that is crucial - I have internalised (or at least am about to). I did some live coding videos actually having a piece of paper by my side with the whole code on it. That is also a way but it did not really satisfy me. The other extreme is coding from the scratch. Fun to do but sometimes I would want to kind of have an inbetween way to pratice:

So I came up with the idea to develope my own shorthand to - on the one hand - have a way to recreate quite complicate tracks and on the other hand to slowly memorise it because the shorthand only gives hints but not the full code. The overall idea is to slowly build up a number of tracks as a sort of repertoire (and thereby extending all sorts of capabilities like memorising, debugging, vision of code and resulting sound aso.)

Here is the simple example of a kick drum (short/code)

# kick beat
# hpf cu 30
# lpf cu 70
# s vox 40 a 0.01 a_lev 10 r 0.125 st 0.125 fi 0.35 ra -0.25 am 0.25
# s 1
live_loop :kick, sync: :beat do
  stop
  with_fx :hpf, cutoff: 30 do
    with_fx :lpf, cutoff: 70 do
      sample vox, 40, attack: 0.01, attack_level: 10, release: 0.125, start: 0.125, finish: 0.35, rate: -0.25, pan: 0.15, amp: 0.5
    end
  end
  sleep 1
end

To be clear: That’s an exercise to answer one question (at least partially): How do I ever manage to live code one of these tracks I developed while working with Sonic Pi without having to live code and thus - with time. I don’t do it enough but found out that (regularly done) can largly incease my coding abilities.

Limiting material and options

Limitation is the answer to creative disorientation (one of Brian Eno’s well known but still true opinions). Finding out, what you can do with one sample might be a bit hard (because your mind wanders around thinking of this or that bassline and breakbeat that could well go with it), but leads to interesting solutions. Moreover in terms of live coding I think it helps 1. to explore the options of one tool in depth (e. g. ‘sample’) and might be easy to handle (because you studied the material like it was the only thing to work with after you stranded on a desert island and thus do really know it well).

One related challenge I came up with for myself is a folder of samples: I only have the path and a slight idea about what the folder contains. I start with using ‘sample path, 0’ and try to make something out of it. I am allowed to use 3 samples from this folder. I also should do this more often…

I do think that in world of multiple options (synth?! sample?! midi?!!) the power to limit myself is a key component of getting along. I am trying to do it more often and more consequently (nevertheless, once I started from a limitation and build something, it can also be a good idea do get rid of the self-imposed limit and run wild).

So, these are just some ideas concerning live coding and the practice of it. Do you have others?


Hi, I'm Mike from western NC
Geneva Live Coding Exercise
#2

Hi,

another exercise coding a Drum’n’Bass tune live called ‘Shireau’. I did use some external effects (especially a nice reverb by Tal, which is available as Open Source). I loaded the plugins into Carla, which is a great tool.


#3

Hi @Martin. Since coming across the live coding concept just a few months back I’ve been pretty fascinated by the idea of writing code as a form of expression. I think what is both a blessing and a curse is that when you have an instrument that is far more powerful than any single physical instrument, you need to deliberately decide and distinguish between how you construct the instrument itself and how you perform with it. With a physical instrument, the construction is pre-determined (e.g. a guitar has 6 strings and an output) and if you want to perform with it you need to learn and practice. With Sonic Pi, I can have an entire orchestra ready to play what I ask. I can even have all of their parts pre-written and ready to play as soon as I say go. But then where is the expression in that?!

I’m still figuring this all out but, what I’m aiming for is to have a personalised library of drum one shot samples and synth VSTi presets at my fingertips. Then I lay out the live loops (one per drum or synth sound) then call functions I’ve written to simplify the triggering of samples in a rhythm or playing a series of notes. If I get good enough, I’m hoping I’ll be able to write an entire song from scratch LIVE with just this framework as a starting point. But, in the meantime, I’ll probably have a number of song “skeletons” ready to go then build on and transition between them as the performance.


#4

Hi @aen1gma, hi to the others,

thanks for taking the time to write down your thoughts. As you I am still figuring out what it is about live coding. Please let me expand your thoughts on the base of some of my ideas and experiences.

You are right, one of the important aspect here is, that you are dealing with a complex instrument with many options. Certainly it is true that a lot of practise as well as experience (=practice) has to go into it. If you go on stage and want to play Jazz (let’s say of average quality - if there is something like that) you will probably have practised your instrument for a few years, involving everyday practice.

Nevertheless this comparison also calls for some thoughts on the differences between say a Jazzer and a Live Coder (bearing in mind that the differences can be sort of gradual):

  • As a Live Coder you are not as dependant on your motoric skill and coordination as a Jazzer. It is certainly very helpfull to be a fast typer but to play an instrument does involve some other and much more complex motoric skills.
  • You don’t have to practice timing the way a Jazzer has to. More you are dealing with let’s say something like circa-timing which involves being able to feel phrases and (depending on the genre) more or less regular rhythical divisions. Actually your instrument does the micro/precise timing.

But - granted you are not simply switching loops on and off - you are dealing with some sort of cognitive overload (well, the Jazzer possibly also, but let me stress the characteristics of the live coding instrument and the situation):

  • You are composing and performing in real time (quite similar to the Jazzer) meaning you have to have a grasp of the musical material you are dealing with (notes, chords, samples, rhythm etc.). More particularly you have to compose the overall structure of tension and release, the developement of interesting musical structures and dynamics like a composer-performer-conductor in one and the same person. You might do this for and with several sound streams (the idea of an orchestra) at the same time.
  • Certainly you have to know your tools i. e. know the language, parameter aso. Although I try to avoid complicated constructs in my experience a live situation makes me even forget the simplest things. The only way to fight this is more routine.
  • You have to have a lot of experience about cause (code) and effect (sound): How does some code will influence what’s going on soundwise?
  • You have to be aware of all the parts fitting together which involves knowing what (more or less exactly )is happening right now, or in easier words: What live_loops are running and what do they contribute? Why did the hihat loop just stop right now? Is it the amp? Something more serious?
  • You are so to say your own sound engineer: You have to control the overall sound because a bass line which is too loud can spoil the whole thing. Certainly not all of this has to be done all live (you can prepare a basic setup), but you will have to take time and invest in a controlled and reliable setup (involving quite different technical areas and tools you have to master) you exactly know how to handle.

To tackle all these challanges my (very personal) program involves the following:

  • Similar to you I am trying to build up a sample collection I know and like. I am consciously trying to limit this collection as I think it is more important to work with it than to constantly look for a better sounding sample.
  • I try to establish a setup (still experimenting) which allows me 1. to run it with more or less one call 2. be able to run a softsynth and/or an effect (which I am currently exploring Carla for) and 3. which I can rely on at least 95% for future live presentations
  • As I believe it is worthwhile to build up a ‘vocabulary’ I try to create complete tunes (or ‘collections of consonant live_loops’ :wink: ) for which I then write a kind of score. Then I try to recreate (and definitely change and refine) these in a sort of live situation. One way to create such a situation is to switch on the screenrecorder and imagine that I want to have a somehow decent performance recording in the end.
  • I quite regularly note somehow generic musical solutions/problems in code. The important thing here: solutions don’t need to be very sophisticated codewise but have to work and should for me be easy to remember or construct (this requireent is definitely shaped by me having some limitations as how abstract I am able to think when programming is concerned)

I found that I do need about 20 minutes to recreate/perform a track with - let’s say - 5 to 7 live_loops. That is of course just some bloodless statistical informaton but checking out my own performances (which I do like musically) I found:

  • It takes probably to long for an average listener (again: if there is something like an average listener, so to be more clear about that: it takes to long for me as a listener - not as a coder)
  • I am struggling with the balance of preparation (snippets) and live typing: I actually want to use rings with maybe 16 different notes or a patterns with 16 or more items but in a live situation - I imagine - it takes to long, is error-prone and just repetitive. On the other hand I feel somehow obliged to type in everything (as a ‘real’ live coder :wink: )
  • I do need my ‘score’ as mentioned earlier. This is meant to be as preliminary (to build up the vocabulary) and even more: it somehow brings me closer to live coding because I can live with the results. I am - meanwhile - able to do a live presentation just inventing things on the fly but for doing a live coding set I would want some other quality as playing around with pentatonics.

So, uuuii, this is a quite long post. Hope it is not boring to read.


#5

Definitely not boring!

My approach to livecoding and improvising code has simply been,what kind of mood is my code going to set?

I tend to juggle different sound effects but mainly I like adjusting the euclidean rhythm plus tempo and let the rest fit in.


#6

Hi @illestpreacha,

that’s a clear and confident approach. I like it :slight_smile:


#7

Hi @Martin,

It does take practice and getting a feel of what effects and combos sound well together. Also working from simple building blocks helps keep me intact with my ideas,easier to draw upon.

I can say my goto work flow is first sounds then tempo/pattern,then effects and after that alteration.


#8

Great analysis. Being a guitarist I used to be somewhat biased against electronic musicians, seeing them more as “engineers” than “artists”. To me, performance is about expression and engagement with the audience, and watching someone pressing buttons and turning knobs just didn’t do it for me. But I think there’s something a bit more “human” about watching someone write code as a performance. I don’t think it really matters how much code they write… just that listeners can see the interaction between the performer and the sounds they hear and get an understanding that it’s the human in control of how a song “feels” (not the computer).


#9

Hello all. I teach Sonic Pi in my 8th grade CS class. While I love music, esp the blues, I’ve found that doesn’t always translate into good Soni Pi-ness. First, playing the guitar is very different from coding, and secondly, I found I did not have an adequate “vocabulary” of sounds, beats, etc. from electronic music.

So I have been spending lots of time lately just listening to electronic music (Tycho, Boards of Canada, Bonobo, etc.). This is helping me build up a vocabulary of sounds and beats. I feel this will really help me in teaching my students.

My other thought here about live coding comes from my experiences playing out at blues “jams”. There’s a lot of improvisation that happens at a jam, and I love the personal interaction and creation that happens when it goes well! But the blues is actually very simple music. All of the players know the basic constraints (keys, I IV V, turnarounds, etc.). So within those simple constraints, we can create something live.

So as I look at live coding, I think that the best approach might be to keep it very simple and then change the sounds. For instance, lay down a simple beat live_loop, then a simple bass live_loop, and finally a melody live_loop. Do most of the changes in the melody loop, first with synths, then opts, then perhaps timing with the rate command. There are so many possibilities with a simple melody that I feel that I can work with that for 5 minutes easily.

And as I do that, I become more comfortable with the different commands and how they change the sound. And then build out from there.

My summer thoughts, now that I have some time to play! Your thoughts?
Bob


#10

Absolutely hit the nail on the head there, Birv, nicely put.
I’ve been wanting to comment in this thread, but you just
did it for me.

Eli…


#11

Thanks, if this was meant to refer to my preliminary analysis.

And: Allthought this describes my somehow ambitious vision of what I think live coding is about I would like to foreground: I am having fun trying to accomplish that and I am happy with what I know and am able so far (without wanting to leave it like it is).

This is to say: Cape diem :wink: