Hmmm,
Im not sure how this relates to other peoples performances,
but i tend to start with some basic and easily reconstructable devices,
such as drawable wavetables and toggle sequence note lists.
>From then on its where things get a bit more hazy, bt hopefully by then
there is enough meat on the audio bones to allow for some room to play.
I agree that a small group is best, as the differnet players can compose and
commit their ideas
at different intervals and fill for each other. But all this is similar to
traditional
improv, basing on a particular scale and backing up for someone elses solos.
I admit that less composition takes place 'offline' (ie in the performers
scratch space brain)
and more happens in a fluid way with the instrument, but this just goes back
to the old
immediacy of physical instrument/ dislocation of programming thing....
I dont think u will ever be able to get rid of this dislocation as
instruments are designed to be played as fluidly as possible for the
specific purpose of
making music, Programming is of course not..
Programming encourages all the the mental acrobatics that alex mentioned,
its a different medium, ofcourse.
DOesnt bother me though, i quite like watching someone slave over a hot
command line,
only to hear some error and watch them sweatily recompile.. its all part of
the fun
and better than listning to a wave file... (or is it ;)... only jokin..
Tom
---------------------------------------------
http://www.nullpointer.co.uk
http://www.codepsace.co.uk
http://www.r4nd.org
http://www.q-q-q.net
----- Original Message -----
From: "Nick Collins" <nc272_at_cam.ac.uk>
To: <livecode_at_slab.org>
Sent: Saturday, August 13, 2005 10:03 AM
Subject: Re: [livecode] time and livecoding
>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.
>
> 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...
>
> I often cheat outrageously, because I'm too busy in something like klipp
> av to allocate any real idea-time. The best I can offer is some variation
> on an existing algorithm where the improvisation seems to allow it within
> the large-scale time constraints.
>
> But my best live coding has always occurred when there is someone else
> there, who can take away the moment to moment demands of the audio (video)
> output audience while I fall into algorithm-world and fabricate. Coming
> back up from such constructions, I am ready to perform in real-time more
> effectively while someone else submerges.
>
>
>
> --On Friday, August 12, 2005 4:18 pm +0100 alex <alex_at_slab.org> wrote:
>
>>
>> I've been thinking about how difficult the relationship between time and
>> programming is. In fact I've been thinking that certain kinds of
>> programming might happen outside of time. When programming, it often
>> doesn't feel as though I'm working towards a whole, but that I've
>> started with a whole in my head and am jumping around it until I've
>> visited and described every part of it, at which point it exists in an
>> executable state inside the computer. It doesn't feel like a journey,
>> more like the simultaneous setting together of different pieces. When a
>> program is complete, it's a surprise, a snapping out as I realise there
>> is nothing more to do, a snapping back in to linear time as I prepare to
>> run the program I've written.
>>
>> However while I'm programming I'm getting a bit older, and so are the
>> people around me. So if during a performance I step out of time to see
>> an idea as a whole timeless structure and transfer it into a computer,
>> where does that leave co-performers, or indeed the audience?
>>
>> 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.
>>
>> I think this is why my from-scratch livecoding in a musical
>> collaboration and/or in front of an audience hasn't been successful -
>> composing from scratch within the constraints of a live performance has
>> been too much to deal with - mixing non-linear thought with linear
>> thought. It's too hard to have a big idea and then find a way to
>> program it that allows a sound to gradually develop - because my thought
>> process of programming hasn't been linear. Much easier to start with
>> something I've made earlier and make variations on largely pre-meditated
>> developments.
>>
>> On another theme, Nick often talks about the "haptic rate," if I
>> understand correctly this is the ratio between our bodies and the speed
>> at which we can trigger sounds with them. With the livecoding systems
>> I've found so far, it takes many seconds if not minutes to go from
>> decision to action - very high latency - but then that action can
>> trigger many other actions at speeds at the very limits of our senses.
>> So we've exchanged awesome speed for dreadful lag. This is made all the
>> more difficult because the lag doesn't exist for the composer, who is
>> too concerned with relating their non-linear composition to the computer
>> to really sense the time they are using.
>>
>> Perhaps the problem I keep hitting on here is that the composition isn't
>> born only inside the programmer's head but also in the computer. In
>> this way of looking at things the programmer starts with a small
>> fragment of an idea, and builds it through small actions to and
>> reactions from the composition as it grows inside the computer.
>>
>> How do others feel about time while they are programming?
>>
>> alex
>>
>>
>
>
>
>
>
>
Received on Sat Aug 13 2005 - 17:34:56 BST