one simple thing that can help on the visuals side would be just adopting
the "variation in proportions" graphic design principle - assuming this
can be done without interfering with the actual coding. that is, different
people using different size fonts (and possibly shells.) this
would a) vary the proportions of the coding images,
and b) amplify the kinetics of typing (because movement would be bigger
too.) of course, it would be difficult to code with everything at 72point
font, so something would need to be worked out - maybe on a shell by shell
basis.
one thing that made things this time look a bit static and and the same
time visually chaotic was that we had a lot of screens this time
(supercollider?) which were mostly/entirely small text in one big shell,
with seemingly little movement. and then when we switched between them, it
wasn't always readily apparent we had switched. this was easier in aarhus
where the coding environments seemed more visually varied and kinetic. for
example, the PD interface there, though it blew everything out with its
whiteness, was quite kinetic.
of course, the best thing would be a rehearsal - coordinating visuals of
10 people without a rehearsal is a crapshoot at best... but obviously this
is a problem of having a) time and b) projectors, or at the very least
monitors so you can try to imagine what the superimposition would look
like.
other things that would help would be more flexible switching hardware (a
second presentation jockey, for example), but those cost some money. and
possibly just sticking with 2 projectors superimposed all the time. for
next go round, among other things, i'm going to add a "blackout" key to the
thingee so it can just make its projector cut to black sometimes... that
could serve a similar purpose.
anyway, we should realize this is a right strange undertaking both
auditorally and visually, and any time you "invent the wheel" with a novel
kind of performance project (or most anything else) it always takes some
tries to get it "right".... so hopefully we can have another
big toplap/poplap/stopgap jam soon so we can keep practicing! ;-)
-_at_
On Tue, 15 Feb 2005, Dave Griffiths wrote:
DG> On Tue, 15 Feb 2005 07:01:46 -0800, Craig Latta wrote
DG> > Nice comments Ade; thanks.
DG> >
DG> > > Encouraged through our remarks that we'd be listening to each
DG> > other > however, she felt this was clearly not happening during the
DG> > > performance...
DG> >
DG> > Yeah, I agree. It was an exquisitely frustrating experience in that
DG> > regard for me... I wished very much at the time that we were doing a
DG> > multi-night gig, with opportunities to discuss how things went on a
DG> > previous night, and informed retries afterward.
DG>
DG> I guess the encouraging thing is that these problems are not faced through
DG> anything *particually* to do with live coding itself, but more basic problems
DG> with communicating during a performance.
DG>
DG> Some sort of enforced structure would be very helpful in these situations I think.
DG>
DG> Perhaps roles should be assigned (drummer/bass/lead type of thing)
DG>
DG> A really pure livecode jam would be to work on one piece of code, like a
DG> highly compressed software project using a live type of concurrent source
DG> control. Then we'd be forced to read/listen to what everyone is doing. We'd
DG> all be working on one thing, not splitting off in multiple directions (maybe)...
DG>
DG> dave
DG>
Received on Thu Feb 17 2005 - 00:25:56 GMT