On Sun, 2005-08-14 at 11:11 +0100, dave griffiths wrote:
> 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! :)
I don't doubt there is massive room for improvement in livecoding
languages but I don't think the fault is all in the language. There are
languages designed for big maintainable applications, and there are
languages designed for quick hacks. I happen to use one designed for
quick hacks :) It seems quite suitable for me.
I think the problem is that we are communicating in rich, usually
textual languages and that richness comes with necessary overhead.
Although saying that it strikes me that body language is also very rich
and doesn't come with this overhead. But then body language is only
rich when it is subconscious, once you try to control it, it becomes
shallow and simplistic.
In that case our problem is that we are using 'higher' brain functions.
> you're talking extreme livecoding: http://www.pairprogramming.com/
> we should try sharing computers some time.
Yes!
> 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?
Not really, it's possible to get the code to edit the variable
declarations in its own source-code but that's fairly pointless as it
has access to the variables in memory anyway. That's only useful as an
easy way of saving state. In that case I usually save the state in
comments and then have the code read back values from those comments...
Somehow its easier that way.
> 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.
Interesting... It's a well-visited idea to take environmental
parameters for a live music performance, but I think it would be just as
valid for a livecoding musician to write code that reacts to light
changes triggered by an engineer, or take parameters from a livecoding
VJ about the how busy/big/intense etc their VJing forms are.
And of course you can write some code that makes music that develops
over time by itself. An interesting area of livecoding research I
think... Writing something live that happens in five minutes.
> 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.
For me it's absolutely a better way of music. I can't play musical
instruments very well, and was getting really fed up with running
pre-written scripts, without feeling compelled to develop them further.
I was trying to collaborate with improvising musicians and getting
nowhere because I just couldn't react to what they were doing fast
enough.
And of course as Julian points out, playing live is only one option for
a livecoder. Livecoding seems a perfect way to compose in general...
It's like describing your musical style to a computer, then playing with
it there to find a composition within.
That sounds like another reason not to rely on coding from scratch in
front of a live audience actually.... If writing something from scratch
is an attempt to define a new style, whereas manipulating a new script
is an attempt to develop your style. In those terms, which sounds the
most sensible approach? :)
alex
Received on Tue Aug 16 2005 - 23:11:28 BST