>Ge:
>> >What is our stance on combining non-livecode
>> >software with state-approved systems during performance?
>
>Interesting question!
>
>> Maybe we should put out a licence (lcl) that disallows linking to any
>> non live coding system..
>
>Heh, I agree. It's easy, and perhaps useful to make idealistic
>statements like "If software isn't written live, or interacted with,
>then it is not a performance." While I these statements are useful for
>discussion and self-reflection, I don't think they should bind anyone.
yes, I would agree that these kind of statements do not lead very far.
What is a 'performance' depends to a large degree on the context -
and if something is set up as performance it is likely to be
considered one.
>To be honest I am sceptical about whether reading and understanding the
>code that a livecoder is making could really enhance the musical
>experience. The interactions between musical processes are more
>interesting than the musical processes themselves (the whole being
>greater than the sum) but you can only read one thing at a time [1]. So
>perhaps it's better not to read one subroutine at a time, and to instead
>listen to all of them at once.
The question is when you hear a change in music that seems to be
somehow externally caused you will try to relate it to something.
Dependent on the change and the expectation you might relate it to a
slider movement, a new preset loaded into the program, or a change in
a text that stands for the sound. Reading the text might, and this is
what I would hope for if just in time coding should be worthwhile,
change the way I percieve sound phenomena and their interactions as
well as make me aware of the active qualities of written text.
>
>[1] From "The raft" by Jose Saramago (in translation):
>
>"Writing is extremely difficult, it is an enormous responsibility, you
>need only think of the exhausting work involved in setting out events in
>chronological order, first this one, then that, or, if considered more
>convenient to achieve the right effect, today's event placed before
>yesterday's episode, and other no less risky acrobatics, the past
>treated as if it were new, the present as a continuous process without
>any present or ending, but, however hard writers might try, there is one
>feat they cannot achieve, that is to put into writing, in the same
>tense, two events which have occurred simultaneously. Some believe the
>difficulty can be solved by dividing the page into two columns, side by
>side, but this strategy is ingenuous, because the one was written first
>and the other afterwards, without forgetting that the reader will have
>to read this one first and then the other one, or vice versa, the people
>who come off best are the opera singers, each with his or her own part
>to sing, three, four, five, six between tenors, basses, sopranos and
>baritones, all singing different words, for example, the cynic mocking,
>the ingenue pleading, the gallant lover slow in coming to her aid, what
>interests the opera-goer is the music, but the reader is not like this,
>he wants everything explained, syllable by syllable and one after the
>other, as they are shown here."
>
>Perhaps this doesn't apply to a computer, which can have or emulate
>multiple processes. But does it apply to a human reading code or not?
I think reading is not a process that really resembles a line from A to B.
Specially when reading code (or magazines) it resembles much a strolling about,
having a look at this, then at this - with the knowledge of each
forming the context for the next. It turns out to be quite a wild
montage of various bits of understanding. Even if reading a novel
usually means going from one word to the next just as from one page
to the next, this does not mean that the understanding builds up this
way - an extreme case is maybe modern literature, but also many
philosophic texts are more like a sculpture that wants to be looked
at in various moments of the day, in different light situations. Live
coding seems to me like an interaction with a kinetic sculpture,
which can be only understood really by changing it. If code is an
instrument, then playing it means changing it, if it is an
environment, then understanding is means constructing experiments in
it. In a novel I can make deductions - I can predict and retrodict
events and reasons for behaviour. I would find it interesting to see
the search for such experiments and causalities becoming a stronger
part of perceiving algorithmic music.
--
.
Received on Fri Oct 22 2004 - 09:03:09 BST