On Thu, 20 May 2004, alex wrote:
a>
a> Amy, you just brightened up my day! Can't wait to see this. Definitely
a> must be part of the runme/dorkbot citycamp.
a>
cool! i hope to get its visuals more varied and a bit more controllable by
then, so it can be at least mildly entertaining for a few minutes. right
now it has a frequent tendency to look a bit too much like a bad knockoff
of a mark napier piece. but hopefully won't be too much work to give it a
bit more variety.
and i can't wait to see feedback.pl in action!
a> Live coding does open up some interesting experiments in feedback
a> loops. Which is good, because it seems to me that the whole point of
a> performance are feedback loops of one kind to another... Between the
a> performer and the audience, between the performer and the environment
a> (accoustics, etc), between the performer and her creation and so on...
a>
hmm, that really pushes/questions the definition of a feedback loop
doesn't it! everything could be a feedback loop - feedback between a
person and the world... kind of existential...
but this brings me to a couple philsophical/practical live coding
questions i ran into while working on the Thingee. Thingee is written in
lingo, so at first i started just typing lingo commands on the screen for
what i wanted to do. then i noticed, the commands were in some cases
uncomfortably long; i had a tendency to mistype, forget syntax, etc.
so i did what i would do in a "normal" application of course - write my
own routines. then i can type shorter commands.
ok, so now, is that still "live coding"? because by this line of thinking,
i could just assign a keypress rather than typing the name of my routine.
then it wouldn't seem like live coding at all.
so this reminds me of the fact that using and programming are really a
continuum when you get down to it... every language is a piece of software
running on top of machine language; every programmer is a user of the
language in which they're programming...
so where do we draw the line? number of keystrokes seems not to be a
productive way to think about it. i looked through the wiki and the paper
draft, and sort of found this all being questioned but not quite answered,
which is probably a Good Thing, because in my gut i think there's not an
answer. the gist seems to be writing algorithms in live performance: but
then again, we're almost always starting from algorithms that exist. for
example, if i want an object to start continuously rotating, i could write
in lingo
sprite(3).rotation = sprite(3).rotation + 10
but typing "rot" or "rot 3" or "rot 3 10" would be preferable. can i
predefine a "rot" routine or do i have to actually write it while i'm on
stage? requiring it
to be written on stage seems to me to privilege the existing language
(lingo) too much as the basis from which everything must spring. and
"rotation" is a pre-existing algorithm anyway.
this example may be too simple to illustrate the dilemma effectively, but
imagine it was something more complex, involving screengrabs, a for loop,
and some other transformations perhaps...
in my gut i feel like this is like the "what is interactivity" question
from a few years ago. and the answer is, "admit there isn't any, but
don't let that stop you from doing it." with interactivity there was a
myth that the artist was giving away control of the piece to the user -
but in fact,
the artist was still in control. with live-coding, there is a myth that
the performer is in control of the software/music/images - but in fact,
he's still being controlled. and yet, once we see through the myth,
there's nothing inherently bad about interactivity per se, and now that
all the controversy's died down, it's often used quite well and without
much fanfare in projects even by folks who decried its existence - just
for what it is - giving the user some physical participation in a project
without claiming to give him "control." the same might be true with live
coding - perhaps it's important to recognize that live coding just moves
the program along the scale of participation between user and CPU, but
there's many levels of control in between. (and that even at the "user"
level, it's possible to take an unexpected degree of control, just as at
the programmer level it's more than possible to lose it.) what do you
think?
i also have a more directly practical question, but i think i will put
that in reply to nick's post...
-_at_
Received on Thu May 20 2004 - 21:26:31 BST