There is something about artist-programmers, the way they’re caught using general purpose languages and tools in specific, unusual circumstances. Many of the basic assumptions underlying the development of these general purpose systems, such as errors are bad, the passing of time need not be structured only minimised, standards and pre-defined plans are good, etc, often just don’t apply. It’s not that artist-programmers can get away with being bad programmers. Far from it, in my opinion they should be fluent with their language, it’s no good being baffled by syntax errors and spaghetti code while you’re trying to work out some weird idea. However if you are following your imagination as part of a creative process, then established and fashionable software development methods often look arbitrary and inhibiting.
The last few days I’ve been thinking about revision control. Revision control systems are really excellent and have a great deal to offer artist-programmers, particularly those working in groups. What I’ve been wondering though is whether they assume a particular conception of time that doesn’t always apply in the arts.
Consider a live coder, writing software to generate a music performance. In terms of revision control they are in an unusual situation. Normally we think of programmers making revisions towards a final result or milestone, at which point they ship. For live coders, every revision they make is part of the final result, and nothing gets shipped, they are already the end users. We might somewhat crassly think about shipping a product to an audience, but what we’re `shipping’ them isn’t software, but a software development process, as musical development.
Another unusual thing about live coding revisions is that whereas software development conventionally begins with nothing and finishes with a complete, complex structure, a live coder begins and ends with nothing. Rather than aim for a linear path towards a predefined goal, musicians instead are concerned with how to return to nothing in a satisfying manner. Indeed perhaps the biggest problem for Live Algorithms is the problem of how to stop playing. The musician’s challenge is both how to build and how to deconstruct.
There are two ways of thinking about time, either as a linear progression and as a recurrent cycle or oscillation. Here’s a figure from the excellent book Rhythms of the Brain by György Buzsáki:
“Oscillations illustrate the orthogonal relationship between frequency and time and space and time. An event can repeat over and over, giving the impression of no change (e.g., circle of life). Alternatively, the event evolves over time (pantha rei). The forward order of succession is a main argument for causality. One period (right) corresponds to the perimeter of the circle (left).” (pg. 7)
This illustrates nicely that these approaches aren’t mutually exclusive, they’re just different ways of looking at the same thing. Indeed it’s normal to think of conventional design processes as cycles of development, with repeating patterns between milestones. It’s not conventional to think of the code itself ending up back where it started however, but this can happen several times during a music performance, we are all familiar with chorus and verse structure for example, and performances necessarily begin and end at silence.
So where am I going with this? I’m not sure, but I think there’s plenty of mileage in rethinking revision control for artist-programmers. There’s already active, radical work in this area, for example the code timeline scrubbing in field looks awesome, and Julian Rohrhuber et al have some great research on time and programming, and have worked on non-linear scheduling of code changes in SuperCollider.
As far as I can see though, the revision control timeline has so far been treated as a linear structure with occasional parts branching and remeeting the main flow later on. You do sometimes get instances of timelines feeding back on themselves, a process called backporting, but this is generally avoided, only done in urgent circumstances such as for applying security fixes to old code.
What if instead, timelines were of cycles within cycles, with revision control designed not to aid progression towards future features, but help the programmer wrestle their code back towards the state it was in ten minutes ago, and ten minutes before that? Just questions for now, but I think there is something to be done here. After all, there is something about artist-programmers, the way they’re caught using general purpose languages and tools in specific, unusual circumstances.
One attempt of interactive revision control that I’ll always look back to fondly was the Shreditor in the Audicle:
http://audicle.cs.princeton.edu/doc/faces/editor.html
Every time you made edits after running a process, it would separate “revisions” of before and after. So it was easy to bring back old versions just by clicking. Simple, it was a bit unmanageable after a little while and the navigation didn’t render it as a tree (just as strings of dot separated numbers for each revision branch), but it got the common case (having immediate access to every step along the way) really well.
In this case, file-based revision control is a bit heavy and doesn’t fit the interactivity requirement for these kind of recall tasks, besides not integrating into livecoding environments well. I guess that’s why most of these “interactive revision” systems end up being built in the languages of their target environments–like a more wide-ranging system like History.sc from JITlib.
Very interesting ideas!
In my work, resumable snapshots of the entire system are common; other virtual machine systems like VMWare give a similar experience. For more fine-grained revision, I had to write something myself, unfortunately.
-C
This is a response to just one comment. Does a performance necessarily need to begin and end in silence? I can imagine a system of controlled feedback, resonance, and echo, plus continual sampling. It’s rarely silent just before a performance; there’s usually talking, shuffling, or applause from a previous performance. There are plenty of systems which do nothing when given nothing, but do a relatively defined thing for broad classes of random input, like the Karplus-Strong string synthesis algorithm for a simple example. This suggests a performance where the noise before the performance is gradually transformed to music, and the audience could interact with the system. You could even end back where you began (roughly) and possibly avoid ending in silence as well.
That’s a really great thought Derek, of digital instruments resonating with the space they’re in.
And isn’t the background noise you describe what Cage called silence? There’s always *something* to listen to, after all.
Those are very nice thought, I also started some day to record the history of my practice sessions at home, and some people told me those histories were a good starting point for them to see how the music and code develops from the beginning. But a linear history as a backup document can be nice, but for a performance is maybe a very large list of executed code to be reviewing while performing.
I would like a kind of a tag/bookmark approach. In a text document one usually use different places to send little commands, so in a history would be nice to see where did this happened.
Unfortunately (?) text documents are made for reading from the top to the bottom, and when the code gets larger and larger is nice to have some scrolling helps, and that combined with a kind of VC would be really good. As I say, a king of a tag approach. One usually know when one start adding something new to the existing music, that would be the opportunity to tag the actual code (let’s say Part 1, or Verse, or whatever) and getting back to it ater on, when the other part is already performing. I do sometimes things like this with the undo command… but then I can’t redo things… would be really nice to be able to cycle between the parts (tags), that would add more structure and dynamic to the music, than the usual linear (or curvy) development/performance.
Thanks for sharing these thoughts, it got me thinking more about the linearity of the performances, more than the linearity of version control (for me at least).
For this kind of micro-version management I rely heavily on the undo-tree mode for emacs: http://www.dr-qubit.org/emacs.php#undo-tree
It stores all modifications in a tree structure that you can later navigate to previous edits (like undo) but you can then branch off from a previous modification and then subsequently navigate back to the original branch if that particular buffer state was more like what you wanted.
It really frees you to experiment knowing that you can always unwind/rewind the buffer state at a whim.
Idea as an enhancement for your emacs livecoding environment – block based timestamped undo. So for each of your blocks (whatever is getting highlighted when you trigger an update) have a unique undo list, and put a nice timestamp on each. The timestamp would be helpful for tying the undo structure to the song / event structure. The per-block would let you roll back just a piece. Minimalist like.