Hi all,
Here's excerpts of a discussion which took place on facebook on
projection in livecoding. You can see the complete discussion here:
https://www.facebook.com/yaxupaxo/posts/10152410909151851
Alex:
Really interesting discussion after my talk in York today, very
critical of conspicuous live coding projection. Feels like time to try
turning off the beamer.
Martyn: I'd say if there is a way of screen casting the coding action
to mobiles or a little screen somewhere for those that are interested
that would be less conspicuous / intrusive to the dancing.
Alex: That's more or less what Charles suggested Martyn.
I've always been uncomfortable with projecting, caught between on one
side needing to share the activity behind what I'm doing, on the other
creating an unwanted impression that people are supposed to read and
understand the code. Have tried obscuring it in different ways but
often you just have to use the projector+screen the venue provides.
I did like the Fiber Festival + Steim extreme of projecting the code
on all the walls, so it was omnipresent and therefore somehow less
distracting.
Heather: Noooooooo! Don't hide the code! Code needs to be *more*
conspicuous in digital culture, not less. :) Though as I've said
before, I get a bit of code fetishism when I watch your performances,
and that might not be so great either, though is enjoyable to me. I
definitely don't feel like I need to read/understand it when I watch.
I just enjoy the rhythm / vibe of watching it.
Kassen: There could also be other lights, either controlled
procedurally or by a external light-controller, or the code could be
displayed in a way that links to the music and mood beyond the
contents of the text/symbols displayed. In a regular club I'd never go
for a projected screen as the single source of lighting. Probably not
as the most visually prominent either. Simply projecting words or text
on its own, in a otherwise normal club context, doesn't seem to
intrude on dancing, at least not that I ever noticed. As a entirely
unrelated remark; some mainstream systems for control of advanced
lighting rigs (stuff like displays made up of led strips and so on)
let you live-edit text. Even when the display doesn't allow for
readable text this makes performative live ASCII-art a option (or so I
discovered to my joy)
Martyn: I can see a simple WebRTC setup working with atom (
https://github.com/seansay/atom-tidal ) I imagine there is a plugin
for that already. So you set up a bitly that points to it and any
phones or tablets that want to can see the code change live.
Kassen: "but often you just have to use the projector+screen the venue
provides." If you don't already; talk with the local techs ahead of
time. In my experience too few organisers do as they don't seem to
realise that a venue may have local techies when can and will
accomplish a lot and think along if only they get the time to prepare
in advance. As a performer you may want to try to do this directly and
bypass other layers. I have had situations as a performer where a
organisation would say "no, impossible", while the local techs took
pride in showing how easy what I wanted would be.
Alex: Yes Heather I think this expectation of understanding code might
only be something people who already understand a programming language
get (not that I'm assuming that you're not an excellent coder as well
as everything else. :) This really needs ethnographic research. I
never feel like reading code projections either, by the way..
Alex: Kassen yes all good thoughts.. Getting the projection right in
algorave style things needs this kind of thinking I reckon.
I've not had good luck getting the message through to venues that I
need stereo monitoring lately, so find the idea of trying to talk to
them about projection set up ahead of time a bit exhausting..
Kassen: I try to read them. When I don't understand what is going on I
still feel impressed by small changes in the visual display that lead
to large yet musically sensible changes in the sound.
Alex: Recently I did a performance where a previous performer stood
over her laptop and mouthed the words to pop songs using her vulva,
into her webcam, projected on the wall behind. This is an interesting
comparison with live coding I think, at least it tells me it's best
not to rely too much on shock/novelty value, or you'll have nothing
left when you get upstaged.
Alex: I look at the screen and enjoy the movement and build up of
code, but can't concentrate on reading the code. Then again I don't
really read my own code in detail when performing, I'm too busy
writing it.
Kassen: Alex, if you like I can ask a good friend of mine who is a pro
at doing lights at dance events and does so with considerable skill,
taste and emphasis on live performance (by which I mean; he plays
light mixers like he is jamming along on some sort of organ) whether
he'd like to be put in touch with you and share thoughts on the
matter. I have long felt that the lack of communication between
visiting sound artists and local light-techs is a missed chance. At
one of my first gigs I only heard after I was done playing that
thingsAmy Alexander I think you're on a good track with "I look at the
screen and enjoy the movement and build up of code, but can't
concentrate on reading the code." That to me is what's interesting
about livecoding - the "live" part, not so much the "coding" part.
When I do text-based visual performances, I try to think of the
on-screen text as something akin to song lyrics. When you listen to a
rock band with a vocalist, you generally don't listen to every word
and focus on the story, e.g., and you don't worry that you can't make
out every word, or if you missed a chunk of the lyrics, etc. The
lyrics mainly wash over you as part of the whole experience of the
performance. So you could experiment with ways of making the
projection less about literally reading every word of the code, and
more about the movement. Which could take any form from defocused
projector showing only the fragment of code that's being typed, to
projecting a webcam image of you typing the code on screen (i.e. hands
with part of rescanned screen) processing the text through PD to
display it more graphically, etc...
That probably all sounds prescriptive and too aestheticized, but
actually I'm just brainstorming some possible ideas in between "no
code" and "full readable code." could have been a lot easier and
better if only I had known that I could hand a MIDI clock to the
VJ.... who had been right next to me for the hour that I played so any
random spare cable from my bag would have done.
Alex: Yes that'd be interesting Kassen, thanks. BTW I didn't mean
people shouldn't want to read my code, I meant people shouldn't feel I
want them to read it, just because I'm making it visible.
Kassen: Yes. I get that. It is the difference between playing a guitar
live and shoving the specific fingering and plucking techniques into
their unsuspecting face. Violin players at town-squares come to mind.
Masaaki: how smartly you are producing music has nothing to do with
how good the result is .. pc had become a normal instrument
Amy: I think you're on a good track with "I look at the screen and
enjoy the movement and build up of code, but can't concentrate on
reading the code." That to me is what's interesting about livecoding -
the "live" part, not so much the "coding" part. When I do text-based
visual performances, I try to think of the on-screen text as something
akin to song lyrics. When you listen to a rock band with a vocalist,
you generally don't listen to every word and focus on the story, e.g.,
and you don't worry that you can't make out every word, or if you
missed a chunk of the lyrics, etc. The lyrics mainly wash over you as
part of the whole experience of the performance. So you could
experiment with ways of making the projection less about literally
reading every word of the code, and more about the movement. Which
could take any form from defocused projector showing only the fragment
of code that's being typed, to projecting a webcam image of you typing
the code on screen (i.e. hands with part of rescanned screen)
processing the text through PD to display it more graphically, etc...
That probably all sounds prescriptive and too aestheticized, but
actually I'm just brainstorming some possible ideas in between "no
code" and "full readable code."
Oliver: I'm glad to see this is still a debate.
David: I still think there is still a lot of "potential" in various
circumstances in insisting on projection... Or even things like later
screencasting honestly a performance where the screen was not
projected, from the standpoint of sharing code.
Mike: In my locale, audiences have been captivated by the projected
code and really seem to like it. I suspect it's partly because live
coding is kind of a novelty here. I do see that audiences get sucked
in to just watching projected code; I do wonder if they are missing
half of the details in the music. With the inherent latency in typing
out a musical idea, watching the code might make up for the time spent
waiting for a change in sound - otherwise the listener is wondering
what they're waiting for. I have performed a couple of times when the
projection didn't work due to lighting - the audience didn't know any
different; the only people interested in my code were other artists I
was performing with (they just had a general curiosity about how I
made sound). I've really hit live-coding hard over the past year, and
the longer I do it the more I'm interested in the algorithms and
language capabilities to produce unique sounds than showing my screen.
Ultimately, it's the sounds that are leading me to new places, but
I'll keep projecting my screen as long as the audiences here want to
keep seeing it.
Masaaki: these days .. turntables are just there to do their job ..
some guys are good at making the operation look cool and some do not
even care .. and i think it's gonna be the same for pcs too .. it's
just sooner or later
Giovanni: Thanks to all for the interesting debate. Thanks Alex for
recognising the importance of etnography in this context
Gavin: Seeing the code creates the essential causal visual reference
that was missing from computer based performance. I don't see the
precise place a violinist puts there fingers but it's part of the
performance that I see them play. Seeing the code is part of
developing the language of computer based performance.
Simon: I was in the audience for your talk and performance. Great
stuff - don't turn off the code projector!
Dan: I would much rather see the protection at a live coding event,
give me the opportunity to learn something.
Alex: Coming to the conclusion that projection, or at least being able
to see screens is important (e.g. by live coding within the audience),
but how the projection is done is also important.
Thor: Under normal circumstances I don't think a person performing
with a laptop needs to show what they're doing. Ideally the music
itself is sufficient.
I do find that much live coding (not all) is actually an audiovisual
performance of realtime composition, and as such the visual element is
important. Most often there are periods within the performance where
musical timing suffers due to the performer being caught up in coding.
Understanding that timing would be lost to the audience if they could
not observe the progression of the performance.
That's a strong reason for me. There are many of others, some
expressed above, such as audience engagement, aesthetics, sharing,
education, recontextualising the performer's body, advertising your
system : ), etc.
Ben: nobody likes google glass, but I wonder what happens if you give
each person the choice of what to see of the live coding? like
personal subtitles setups
Jenny: Hi Alex. If you want a layman's perspective, I came to
Liverpool event recently, mainly because I'm interested very generally
in process in music and performance, and in audience experience at
different types of event. And I'd seen clips and heard good things
from epic Algorave groupie Dr Mooney. I really enjoyed it, and it was
great to experience something so totally new to me (I am an opera
scholar) and I think the visual coding element was key to that,
because I was very much in my own space immersed in watching and
listening and feeling it and learning. Another thing - from talking to
people, there were certainly a lot of audience members there who were
regular ravers but unaware of the live coding process. Although they
could see it, they didn't necessarily connect or perhaps have that
level of interest in process. So they had a clue, but if it wasn't
there then any point of interaction on that would disappear and they
wouldn't know or wonder about that at all. So I think it's important
in order to stimulate interest in process.
Alex: Thor, I think *all* music performance is audiovisual, for those
who can see. The activity you see is intrinsic to the music.
I think I probably could tell you the exact number of beats that had
passed since the last time I made a change at any moment during a
performance. Being continually aware of the passing of musical time is
so important to me that I avoid getting caught up in longer term
coding tasks by making a language that is fast to use. I think you are
the same with ixilang, no?
Thor: Yes, that's one of the goals with ixi lang. But I was trying not
to talk about myself and said that I find this often important in the
live coding performances I've seen - i.e., I'd rather have the visuals
for the reasons that the coding is an integral part of the
performance.
Ernest: Often in live coding, normally in fact, the showing of the
code is a kind of side effect or augmentation on the experience. It
seems to me that the issue you are concerned with Alex is to what
extent can the code be an actual component of the audiovisual artwork.
I don't think anyone has solved this but I see it as a vital problem.
If is is part of the work, everything about it matters: the quality of
the image, the font, the layout, colour etc and, most of all, the
experience of reading it, so the language itself. Some lessons from
research in end user programming, for example, might be helpful.
Perhaps we don't have to understand the code fully but just get a
sense of what is going on etc. From this point of view, we shouldn't
see it as similar to hearing a reading of a Shakespeare sonnet whilst
reading the notes about the poem. We should see it as an integrated
audiovisual experience. Can this be done?
Patrick: Needs to be a panel on that at ILCP!
Jonathan: How about materializing the code in another way without
introducing too much interpretation? I always liked the thought of
distributing a printed-on-demand booklet of performance code at the
end of the evening. Maybe you'd even make some cashmoney
Alex: Well Antonio was going to do live coded VJing with my screen as
input for one gig, that would have been interesting if the curator
hadn't intervened
Antonio: We'll do it one day! I really like Fluxus as there is a
direct connection between the code and the visual output. I'm not sure
how you would make the music more visual and interesting to look at.
As Alex mentioned I've been wanting to use the code output as a
texture for visuals but haven't yet had a chance to do this. One day
Alejandro: One interesting part of live coding is the experience of
getting into someone else´s desktop. It is like someone inviting you
home. Maybe is a good idea not to focus so much in the information
avialable by showing the code but the experience of inviting people
into your pc. This could be meaningful if it is done with inventive. I
think showing the screen potentially is a very powerful tool. ¡¡¡Show
us the screen!!!
Tanya: Ahh, the debate... to project or not to project your code, that
is indeed the question! Least we forget the manifesto to rule all
manifestos: "Obscurantism is dangerous. Show us your screens ... Code
should be seen as well as heard, underlying algorithms viewed as well
as their visual outcome ..."
Dan: This is an interesting one for visual livecoding - most of my
live work so far has had code overlaid, and this has been
appropriate/appreciated for things like algorave events or
performances of that kind. I've since moved into using my live work in
other spheres, particularly around chiptune visuals, at which point
the code becomes something I'm using the generate visuals but I don't
feel adds to the experience - in fact when working with fairly
intricate fast-moving live visuals the code overlaid would be a
distraction I think?
One of the next things we're adding to Cyril will be the ability to
manipulate multiple code frames with external editors, for this exact
reason. Definitely depends on the context though - I'm certainly of
the opinion that just because livecoding is something I'm using, I
don't necessarily have to share everything warts-and-all if it doesn't
add anything to share.
Although when I did Superbyte I inserted a comment into my projected
code asking if anyone could bring me a beer, which worked nicely. So
there's that.
Amy: One video I show my audiovisual performance students is Edgar
Winter Group's Frankenstein. We discuss it in terms of how performers
of a new type of instrument (analog synths) dealt with an instrument
that, on its own, made it hard for the audience see the performance.
There's the DIY keytar, and also a few other strategies. A lot of it
looks awkward now, but the point is, we have to experiment and try not
to worry that some things will work and some won't. Social media tends
to make people self-conscious about making fools of themselves, but we
have to suck up and do it anyway.
https://www.youtube.com/watch?v=x1mV_5-bRPo
--
http://yaxu.org/
--
Read the whole topic here: livecode:
http://lurk.org/r/topic/5Mwkd5rlKVRngizupitvSz
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Thu Dec 04 2014 - 09:28:55 GMT