On Wed, 2007-01-10 at 12:04 +0000, Dave Griffiths wrote:
> It's not quite the same thing, but I think there maybe some parallel with
> normal coding practice here, the state of complete concentration while
> programming, having to be disengaged from the rest of the world, losing
> track of the time of day. This must be true of playing instruments too?
I think so.
> So to perform well, you have to be able to enter this state, and produce
> results in a timeframe acceptable to an audience.
Yes.
I think the from-scratch livecoding practice advocated so far is quite
traditional, in the musical sense. Nothing wrong with that, as can be
seen in the results.
It's worth stating that the biggest value of this practise clearly isn't
in getting better at typing. I think it's more about developing a
musical style.
In that case to me internalising musical style through regular practise
seems the wrong approach, for me at least. What we should be doing is
reflecting upon our livecoding style, then externalising by adding
functions and operators to our livecoding language of choice. This is a
really big deal, being able to reflect upon our style and change it is a
unique human skill.
Then it just takes a few hours before a gig to make sure we are familiar
with all parts of our language before a performance.
This isn't the same as having pre-written scripts that we modify.
Actually I think this approach is flawed, starting from pre-written code
just doesn't result in livecoding for me - it results in parameter
tweaking. Ok as a backing track, or emergency fallback position but
nothing else.
On the other hand 'from scratch livecoding' doesn't fit either because
we're not starting from scratch, we're starting from a language
developed for our particular style of music.
> Unfortunately I don't think many languages are well designed for this. For
> example, having to actively think about syntax is not coding - and is a
> barrier to disengaging. At the right level it helps you, in that the
> syntactic rules channel your thoughts into recognised patterns, once you
> are familiar enough with a language for them to become second nature.
Yes absolutely. I now think Perl is completely unsuitable for
livecoding.
> This knowledge comes with normal everyday programming, whether you do it
> in a performative mode or not. Really livecoding practice is more about
> accelerating and restricting yourself to things you know well (depending
> on how confident you are).
Yes, and I think externalising that knowledge into a function is a
really good way of getting to know it really well.
> I totally agree with Nick though, in that we have to have more failures, I
> think I've been guilty of getting too conservative in my approach of late.
I've done some terrible performances lately (not the ones with you Dave,
which have been great fun). I don't enjoy failures but learn much more
from them than successes... And the audience never hate my failures
more than me, so I don't mind exposing them to it.
As ever I applaud Julian's moves away from the performer/audience
separation. I think Martin has a similar point of view and it really
seems an interesting way forward. We should take this on board for the
Sheffield event and try something different. For example instead of
having a toplap members jam, we could instead each make a simple musical
language (or hone down an existing one), and each set up a computer
running an interpreter with instructions for how to use it, and see what
happens. Openlab in London have been doing something very close to this
at their events, calling it "PD wife swap." :)
alex
Received on Wed Jan 10 2007 - 12:36:08 GMT