Ok, great, a figure would be good- I will be writing up this evening, if
you can mail one before 10pm say- just a screenshot of your feedback.pl
program in action, or I'll grab your self code exhibit on the toplap
identity page.
--On Monday, May 31, 2004 5:20 pm +0100 alex <alex_at_state51.co.uk> wrote:
> 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 - 17:00:45 BST