> 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.
programing languages != text
but I see what you're getting at
> 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.
well we could try to figure out a gestural programming language based on a
martial art :)
> 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!
I've done pair programming at work, and it speeds up code development so
much that you get more out than the two people working alone. maybe the
same would be true for live coding?
>> 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.
well, I'm completely lost. bloomin perl programmers :)
>> 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.
yes - more input. I'd like to livecode music where I had some form of data
from the crowd. I think we could do a lot by using more devices like Amy's
dance mat - it would mean we start to use more muscles and less mind.
> 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.
well it's the only way I can make music live - I wouldn't feel right
mixing pre-made tracks, and I can't play an instrument to save my life :)
I think for me (maybe because of my background) livecoding has more in
common with a visual art. When I'm painting, I have a similar concept in
my head - switching between planning from a high level what's going on,
and applying the paint, both informing each other.
> 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? :)
I still think the from scratch approach works best for me, just because it
feels more exciting (although I can't depend on it entirely yet). I think
development has to progress through building the environment in which you
work, writing libraries of often used bits of code, so your building
blocks are more useful. We are programmers after all :)
cheers,
dave
Received on Wed Aug 17 2005 - 09:44:07 BST