I’m doing a talk with Dave Griffiths about live coding this Thursday, from 6pm til 8pm in the Seminar Rooms at Ben Pimlott Building (Ground Floor, right), Goldsmiths, University of London, New Cross, SE14 6NW
Here’s the blurb:
Live coders program in conversation with their machine, dynamically adding instructions and functions to running programs. Here there is no distinction between creating and running a piece of software – its execution is controlled through edits to its source code. Live coding has recently become popular in performance, where software is written
before an audience in order to generate music and video for them to enjoy. McLean and Griffiths have played around Europe together with Adrian Ward as the live coding band “slub”. They will talk about the history and practice of live coding, and give some demos of their own live coding environments.
Alex has been triggering distorted kick drum samples with Perl scripts for far too long. He is a PhD student at Goldsmiths Digital Studios.
Dave Griffiths writes programs to make noises, pictures and animations. He makes film effects software and computer games.
Dave & Alex are both members of the Openlab free software artists collective and the TOPLAP organisation for live algorithm promotion. slub.org ; toplap.org ; pawfal.org/openlab ; pawfal.org/dave ; yaxu.org
THE THURSDAY CLUB is an open forum discussion group for anyone interested in the theories and practices of cross-disciplinarity, interactivity, technologies and philosophies of the state-of-the-art in today’s (and tomorrow’s) cultural landscape(s).
For more information check http://www.goldsmiths.ac.uk/gds/events.php or email Maria X at drp01mc [at] gold.ac.uk
To find Goldsmiths check http://www.goldsmiths.ac.uk/find-us/
I’ve had a paper accepted to ICMC (International Computer Music Conference) in Belfast. My paper isn’t directly about livecoding but according to chatter on the TOPLAP list there will be a fair number of livecoding papers and performances around the conference, including a off-icmc livecoding event organised by Graham Coleman. Looking forward to the schedule appearing…
Just after that from the 29th August is the 3rd annual dorkcamp, a weekend in a field doing strange things with electricity. The previous camps were fantastic, I can’t wait.
Then probably the following weekend, 6th September will be the London Placard headphone festival, an intense evening of diverse back-to-back 20 minute performances over a bank of headphone distribution amplifiers (and no PA). Always extra-special and full of surprises, it looks like this will be a big one…
Joel Laird completed a fine PhD thesis on physical modelling drums in 2001, which included C++ sourcecode for an accurate model of a drum and a felt mallet for hitting it with. I’ve been in contact with Joel and am very happy to have prompted him to license the source under the GPL.
A .tar.gz file including some windows demo programs and the (Borland) C++ source is here. I hope to make some time to translate some of it into realtime supercollider unit generators soon…
I ported it to GNU C++, a version with my edits is available here.
A brand new website:
The idea is that every month some instructions appear and passersby add
their implementations in code.
Please let me know of bugs / omissions / ideas!
I’m working with Jamie Forth on ideas around spaces of rhythm. Here’s a demo (which might not work in feed readers):
The space has two quality dimensions, “intensity” (X) and “disorder” (Y). Drum patterns are arranged along these dimensions, so more intense ones are towards the left and more ordered ones towards the top.
Draw a line from a high hat to a kick drum. If you draw a short line the rhythms will be more homogenous. Certain angles have certain feels to them. Maybe. It seems a nice way of playing with polymetric rhythms as vectors anyway.
Very early stuff but a rendering of the vocable word sebosebesusasobesebosebasusasobesebosebesusasobesobosebesusasobesebosebesusasobesebosebasusasobesebosebesusasobesobosebesusasobe is here.
(any website layout breakage is intentional)
The percussive beat you hear in the background is the excitation of the mesh, bursts of pink noise from the ‘b’s and white noise from the ‘s’s. The vowels control the ‘tension’ of the mesh.
The waveguide mesh ugen mentioned in my previous post and used here is now in sc3-plugins.
After quite a bit of fiddling, I got a waveguide mesh working. It’s a physical model of a drum head, basically lots of bidirectional, single sample delays connected in a triangular mesh to form a hexagon. [update: now a second extern is in there that tessellates a circle instead].
It sounds pretty good already, next plan is to play with different ways of exciting it.
The supercollider plugin, together with some haskell (hsc) code for testing it, is downloadable here.
[update: native sclang code and classes included now too]
[another update: new version with patch from Dan Stowell, it uses less CPU now]
Here’s an interesting response to my earlier post about how test driven development does not necessarily apply to all problem domains. Ocean has some insightful things to say about creativity, but mischaracterises me as seeing constraints as undesirable.
In fact I agree that constraints are essential to creativity. Constraints form the walls of the creative space that a creative agent (here, the programmer) searches within and pushes against. My complaint was not against constraints in general, but in the assumption that when we’re talking about development, we’re talking in the context of writing quality assured business software.
Lets take livecoding as a example. A programmer stands on stage, and has to write some software to generate some music so that the people waiting in front of them has something to dance to. Imagine looking up from your code editor to see the expectant faces above. This particular problem domain is one I have found myself in as a member of slub, and already has plenty of constraints to guide my creativity without adding the extra artificial constraints of starting with some unit tests.
[edit: see comments for fine counter-example from dave (a fellow slub member)]
This entertaining article supporting test-first development has been playing on my mind. The article is beautifully written so it is easy to see the assumed context of working to deadline on well specified problems, most probably in a commercial environment. It saddens me though that we accept this implicit context across all discussion of software development practice all too easily.
Here’s a nice illustration from the article, which appears under the heading “Prevent imagination overrun”.
So there is a fairly clear reason not to write any tests for your code — you will take in more of the problem domain without such directive constraints. What you are left with will be the result of many varied transformations, and be richer as a result. You might argue that this is undesirable if you are coding a stock control system to a tight deadline. If you instead take the example of writing some code to generate a piece of music, then you should see my point. The implicit commercial context does not apply when you are representing artistic rather than business processes as code.
In fact this notional straight line is impossible in many creative tasks — there is no definable end goal to head towards. A musician is often compelled to begin composing by the spark of a musical idea, but after many iterations that idea may be absent from the end result. If they are scoring their piece using a programming language, then there would be no use in formalising this inspirational spark in the form of a test, even if it were even possible to do so.
What this boils down to is the difference between programming to a design, and design while programming. Code is a creative medium for me, and the code is where I want my hands to be while I am making the hundreds of creative decisions that go into making something new. That is, I want to define the problem while I am working on it.
While “end user programming” in artistic domains such as video and music becomes more commonplace and widely understood, then perhaps we will see more discussion about non-goal driven development. After all artist-programmers are to some extent forced to reflect upon their creative processes, in order to externalise them as computer programs. Perhaps this gives a rare opportunity for the magic of creative processes to be gazed upon and shared, rather than jealously guarded for fear that it may escape.
A nice video of the livecoding sessions at v2 last month. Florian Cramer starts with an interesting take on livecoding, and it’s an honour to be mentioned in the same breath as Click Nilson. I should admit though that I was far from being the first livecoder as Florian suggests. SuperCollider server and Chuck were existed way ahead of my lowly feedback.pl, and in slub, my collaborator Adrian Ward was livecoding at least a year before me. In fact powerbooks unplugged who present and perform with their beautiful conversational code system later in that video were doing this stuff long before I livecoded my first gabba kick.