> 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.
I think what makes sense is abstraction - i.e. prewritten libraries.
"Livecoding from scratch" really means starting with a blank screen, as
true "from scratch" livecoders have to write drivers etc first. Starting
with a prewritten script on your screen *is* parameter tweaking, and I do
a bit of that still but it's getting less and less.
Developing libraries is a very important skill for a programmer, as you
have to distill you philosophy of how to solve a problem into easily
managable blocks. I think this is really interesting when it comes to
artistic software, as this interface defines the philosophy you have to
fit your work into.
This could also be called "style" I think.
For example, lately I've been livecoding a script to do things directly to
vertex data on a raw geometry mesh. I've gone about as far as I can go
with this approach, so I'm writing a scheme module to deal with higher
level geometric operations in fluxus - extruding, lathing and skinning.
These will be the building blocks for upcoming performances - but I still
get to start with a blank screen.
cheers,
dave
Received on Wed Jan 10 2007 - 13:25:03 GMT