Slowly catching up...
On Tue, 2004-02-24 at 00:29, Amy Alexander wrote:
> so, i'm very interested in the performative aspects of live-coding.
It would be good to define the different aspects of live coding that we
find on the website as some point. It would make it easier to think
about it all.
> live-coding can invert the usual electronic music performance assumptions
> i think, because it's now coding-as-improv, i.e. live composition, rather
> than software-usage as performance.
I think there could be a subtle but important point here.
A programmer/musician/artist often needs quite a particular and
individual environment in which to work. For example I like to think
about what to program while I'm dancing, decide how I'm going to program
it in the bath, and actually program it in quiet and comfortable
surroundings such as my studio or sofa.
The idea of going to a club, getting on stage, creating a source file
and beginning to compose the next 40 minutes of entertainment is kind of
ridiculous.
So I think a more practical approach is to start with a pre-prepared
composition, but instead of building in interfaces and parameters, you
change the variables and structures in the code directly, and modify the
composition over time to produce (for example) musical progression. As
the code is edited it immediately gets interpreted and the sound
changes. This seems to be how Julian works with his jitlib.
So you can start off with fairly static composition and make changes to
it over time to turn it into a performance.
> 1) is this all about music? (e.g., i work from the visuals side of things.
> then again, i'm not specifically live coding, either... )
No, I think the visual and other mediums are just as relevant, within
the context of time-based performance.
> 2) are we interested in the performative aspects of live coding, the
> conceptual aspects, or both? in other words, is the audience always made
> aware of the live coding process? how? are the performers' displays shown
> on screens? do we see their fingers typing?
As I think I said replying to a later mail; if there is any kind of
visual spectacle as part of a sonic performance or vice-versa, then they
should be closely related. Seeing what is causing (or caused by) the
sound (or the process that makes the sound) brings us closer to the
sound, and so the visual becomes part of the musical experience.
Of course someone could say they have unrelated sound and visuals in
their performance, that this somehow works, and that no-one should tell
them otherwise.
Fair enough - our job at TOPLAP is not to decide what is a perfect
audio, visual or a/v performance, but to define what constitutes a
TOPLAP performance. Ie, a particular type of performance that we think
is interesting, worthwhile and should happen more often.
I don't think we should be trying to define the perfect performance in
general terms.
> 2a) if we're interested in the audience's experience of the coding
> performance - how much of this is about typing vs. coding? i remember from
> alex's impromptul 5-minute coding performance at transmediale last year,
> the audience was very excited to watch alex's cursor fly around in emacs.
> fortunately, alex is not only a whiz at coding, but also moves like a
> dancer in emacs. so now that's 3 things - coding well live, typing skill,
> and a particularly visual facility with a text editor. do we separate
> those issues? for the audience? for ourselves? what about lowly vim users
> like me? ;-) ... and, how to address these issues without degenerating
> into emacs/vi wars?
In my experience, typing is a good way of engaging the audience in
certain contexts but not others... For example an audience which is
sitting down drinking wine might find it engaging to watch an editor
being expertly used.
I don't think projecting the editor above a dancefloor encourages people
to dance however! It's hard to read when you're jumping up and down, so
a lot of people just stand and watch. That's a shame; when you're
dancing the processes really become alive around your movements. You
don't need to see anything.
However, typing is central to a lot of programming activity so should be
flagged up as a useful performative tool.
> 3) is live coding inclusive or competitive? i.e., does one need to be the
> fastest, most proficient coder to do perform live? if so, it might prove
> programming prowess but exclude people with interesting ideas and a feel
> for live performance, but who aren't as quick at the programming end of
> things. or, can both approaches be accomodated, for example, through
> various types of languages?
I agree with Ade that it shouldn't be competitive in general, although I
heard about 'competitive poetry' recently - if poetry performance can be
competitive then why not programming?
I feel that a live coding performance requires some deep understanding
of the code that is being performed with. If the performer was the one
who programmed the code then they will already have this deep
understanding.
So yes, we can be inclusive to a point, but we can only include
programmers.
> 4) from this question, as well as the issue of cubase sequences, it seems
> to me that we've hit on the idea that the distinction between programmer
> and user is really more of a continuum than a line in the sand. and after
> all, programmers are users anyway, using C++, perl, various libraries,
> etc.
Agreed. I think we have to draw that line in the sand somewhere though,
and accept that others will draw it in different places.
> yeah, i'd also vote for keeping things as loose as possible, and then
> providing some rationale for whatever admittedly-subjective line we decide
> to draw (and that the line can be crossed for particular situations -
> what if someone constructs a turing-complete language out of cubase
> sequences? ;-) )
Indeed!
> a> One idea we had was to have TOPLAP ratified programming languages and
> a> programming methods, and a procedure that people would follow to get
> a> their particular programming/performance environment ratified.
> i'm not sure i follow the rationale for this? it sounds a little like it
> could create a feeling of an exclusive club to me like it could discourage
> people from working in new directions... but maybe i missed something?
If the procedure to get things ratified were easy and open, then it's
not an exclusive club.
> sorry if any/all of this is stuff that's been discussed already! i know it
> can be weird when new people join a group and then bring up the same
> things that have been gone over before... hoping to catch up soon! :-)
Like Frederick said, we only just started!
alex
_______________________________________________
livecode mailing list
livecode_at_toplap.org
http://toplap.org/cgi-bin/mailman/listinfo/livecode
Received on Sat Feb 28 2004 - 12:15:20 GMT