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?
) 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.