I'm pretty darn busy myself but it'll all be here
http://twitter.com/annyfm
On 4 December 2014 at 10:43, Aneurin Barker Snook <anny_at_by-anny.co.uk> wrote:
> I added some thoughts on Twitter as well around the same time, but I'm a bit busy right now - would you care to copy those in Alex, as an 'attachment' to the main conversation?
>
> Will read through all of this when I have a bit more time!
>
> A
>
>> On 4 Dec 2014, at 09:28, alex <alex_at_slab.org> wrote:
>>
>> 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
>
> --
>
> Read the whole topic here: livecode:
> http://lurk.org/r/topic/5YeqGSyVGpkKZ8hKe9K35E
>
> To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
--
http://yaxu.org/
--
Read the whole topic here: livecode:
http://lurk.org/r/topic/1PnJJeEcXPIGncYvkZ8Tp4
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Thu Dec 04 2014 - 10:52:31 GMT