On Sat, 2005-08-13 at 10:03, Nick Collins wrote:
> I enjoyed this thoughtful and insightful essay very much.
>
> perhaps there is a spectacle in seeing livecoders wrestle with time
> constraints? Juggling their real-time and compose-time.
I agree completely, the ridiculousness of the situation makes livecoding
fun. We're using languages designed for slow considered construction of
programs that extract information from databases (apparently nearly all
programming boils down to that task). It's a battle - too right! :)
> The most successful performances I've seen so far seem to have involved
> small groups of coders, usually a duo, (10, as in transmediale was probably
> too unwieldy without lots of rehearsal discipline) where one artist can
> play much more in real-time while the other is in idea-time and then they
> can swap. Covering each other's algorithmic backs...
you're talking extreme livecoding:
http://www.pairprogramming.com/
we should try sharing computers some time.
> > Somehow part of me still has to be aware of the music that is developing
> > while another part of me is in the timeless world of programming.
> > Livecoding compounds the problem - the program is executing linearly
> > while I am thinking non-linearly.
When I've been properly livecoding fluxus (ie starting with an empty
script) I've often found myself having to flip between these mindstates,
and it really takes the pressure of a live performance to get into this
properly, it goes something like this:
1. goal driven : make something (usually a cube) move to the sound
2. intuitive : play with the camera a bit
3. goal driven : increase the complexity - add some tree recursion
4. intuitive : add some blur, play with colours, ahhh
5. goal driven : deform the shapes in a more interesting manner
6. intuitive : try some textures
7. goal driven : write a function that modifies the texture coords
8. intuitive : play with the camera some more
It's like the two sides of my brain taking turns. I also tend to write
some code in a forward thinking planned way, then go back over it
changing numbers in a totally absent minded experimental way - I think
you actually have a way of doing this automatically, don't you alex?
>>From my experience, I think it's a lot easier in a way, doing visuals to
sound, as you have an implicit source of data - I can get away with
going into the programming "zone" for a while as stuff still reacts to
the incoming sound automatically. I find audio performances more
demanding - especially solo.
I think there are two points really, there is the punk rock side of
livecoding that wants to get a load of robots playing classical
instruments, programmed live with cobol. And there is the "is this a
better way of making music" argument which is a lot harder to justify,
but maybe not as important.
Maybe trying to design a language specifically for the job, and not
necessarally a text based one, would be in interesting project.
cheers,
dave
Received on Sun Aug 14 2005 - 18:16:09 BST