hello all.
i'm not sure analogies with traditional performance modes are useful,
because ultimately, livecoding is equivelent to a composer coming on
stage and sitting down to write a piece of music while everyone
watches, and maybe with some musicians looking over his/her shoulder
playing what is being written... it just doesn't work, its an entirely
different paradigm.
i think the "in-the-zone" semi-hypnotic state that all programmers are
surely familiar with is just as valid as the focus of a performance as
the "flow" you might feel when playing the guitar. very different, but
equally valid.
there seems to be a lot of work being done in academia in creating
more intuitive controllers for electronic music, with comparisons
constantly being drawn with traditional acoustic instruments. but i
think the post-digital aesthetic works best when the focus is on the
laptop rather than a human performer. thats what draws me to
livecoding - the performer just guides the machine, letting algorithms
largely do their own thing.
i'd be interested to know how "interactive" the programs people here
are writing are.. slub quote from fallt website:
"Computer languages allow us fine-tuned expression. First, we mould a
unique sound environment in code; then, human movement transforms and
guides the musical processes in realtime"
what form does the human movement take? are parameters in the program
mapped to various sliders etc? so this means there are basically two
types of change in a livecoding performance - parameter changes
(quantitave changes of values in the system) and altering the program
itself (qualitative change - a change in the behaviour of the system
itself).
sorry if these are obvious questions (i'm new). previously i've just
concentrated on making the system in its entirety pre-performance, so
that all thats left to do during performance is alter parameters.
pete.
On 10/09/06, Julian Rohrhuber <rohrhuber_at_uni-hamburg.de> wrote:
> Hi Alex,
>
> this is a good line of thought. The incremental process of livecoding
> really is what makes it an act of public reasoning.
>
> I think what comes up here is the notion of a "livecoding piece". The
> nice thing about a piece is that it can be played by many different
> people, each time different and in its own way special. I would
> suggest that a livecoding piece is a piece of code, together with a
> number of simple rules what to do, much like a fluxus piece or a
> conceptual artwork. At times the code can be absent, or the rules can
> be. In a private interactive programming session, I often start from
> scratch, but there is no reason why not to start with a piece of code
> when doing a performance. Excuse the comparison, but it might be a
> good show to build a guitar on stage and then play a song on it, but
> it is by no means the only possible way to do a guitar concert.
>
> // an overly simple example (a bit dramatic nowadays, maybe, but well.)
> (
> a = [];
> f = {|freq|
> a = a.addFirst ({ SinOsc.ar(freq) * AmpCompA.ir(freq) * 0.01 }.play);
> a[11..].do(_.free);
> a = a[0..10];
>
> };
> )
> // start an egg timer
> // think of a random number between 40 and 20000.
> // wait a bit
>
> f.( your number )
>
> // repeat this process until egg timer rings.
>
>
> --
>
>
>
>
>
>
> .
>
Received on Sun Sep 10 2006 - 16:36:39 BST