Re: [livecode] finishing paper

From: alex <alex_at_state51.co.uk>
Date: Mon, 31 May 2004 17:20:47 +0100

Here is my replacement "feedback.pl" section. I hope it reads ok, I'm a
bit close to it at the moment. It's crying out for an illustration, but
I haven't got the resources or the time at the moment...

feedback.pl

A painter, Paul Klee, moves to make a mark on a canvas. Immediately
after this initial moment the first counter motion occurs; that of
receptivity, as the painter sees what he has painted. Klee therefore
controls whether what he has produced so far is good.

This is the artistic process described by Klee in his excellent
Pedagogical Sketchbook [Klee, 1968]. The same process occurs when an
artist edits a computer program. The artist types an algorithm into
the computer, the artist considers it in its place and moves to make
the next mark in response.

However, live programming allows us to play with this relationship
somewhat. Let me describe how my live programming environment,
'feedback.pl' works.

The marks that the artist is making in feedback.pl don't just affect
the artist, but also affect the running code. While the artist
considers the possibilities of a fresh algorithm that they have just
typed, feedback.pl is already executing it.

What's more, the algorithm running in feedback.pl can edit its source
code. I should explain carefully... While the artist types in a
computer program, feedback.pl is running it; that running process may
edit its own source code. Those self-modifications take immediate
effect, changing the running program. And so it goes on.

The running code may also do other things. I use feedback.pl as an
environment to make music. So I write live code in feedback.pl that
makes live music.

And so we have at least three complementary feedback loops. One loop
is that of the artist and their work in progress - expressions enter
the program, the artist observes the effect on the sourcecode and
reacts with further expressions. A second loop is that between the
sourcecode and the running process - the process reads the sourcecode
and carries out instructions which modify the sourcecode, then reads
in its modifications and follows those.

The third, outer feedback loop appears when the program creates
external output. The program might generate some sounds that the
artist interprets as music, reacts to by changing the sourcecode,
immediately changes the process which in turn alters the generated
sound, which the artist reacts to once more.

When I'm performing before a live audience, then there is a fourth
feedback loop, encompassing the audience who are interpreting the
music in their own individual ways, making their own artistic
expressions by dancing to it, which affects the choices I make, in
turn changing the music.

If the programmer is to share the continuous artistic process of a
painter, their performative movements must be must be reactive, they
must be live. Code must be interpreted by the computer as soon as it
can be written, and the results reacted to as soon as they can be
experienced. The feedback loops must be complete.
Received on Mon May 31 2004 - 16:21:00 BST

This archive was generated by hypermail 2.4.0 : Sun Aug 20 2023 - 16:02:24 BST