Yes it does precede, in Alex's work (thanks Alex!) and in prior
(not-always-live, and-or not-always typewritten) arenas such as for
example
http://www.vasulka.org/Kitchen/PDF_ExpandedCinema/book.pdf ,
but it's still an interesting conversation here and now. Appreciations
to Dave and the subthread about less minimal approaches, which are
many and rich.
Even in quiet, only-musical settings, I'm pro-code here, and I see
projection as an interesting formal cue.
Perhaps importantly, it also places musical livecoding squarely in the
domain of process-conscious work.
I do wonder, since I find myself doing livecode performance with
non-livecoders, if it's simply an ensemble or performance decision
like any other. Or does the manifesto, aforementioned, 'encourage' it?
On Fri, Dec 5, 2014 at 3:46 PM, Jeffrey Brown <jeffbrown.the_at_gmail.com> wrote:
> The idea appears to precede me: http://hackage.haskell.org/package/tidal-vis
>
> On Fri, Dec 5, 2014 at 11:49 AM, Jeffrey Brown <jeffbrown.the_at_gmail.com>
> wrote:
>
>> Few of the people on a dancefloor want to be reading text; they want a
>> mood, a beat, and colors and flashing lights that speak the same message as
>> the music. Ideally, I think, the same network of data and instructions
>> that generates audio would generate visuals, so that changes in one domain
>> would map naturally to the other.
>>
>> It is excellent that the livecoding community make their code available,
>> because it lets knowledge snowball. But making the code available does not
>> require making it the visual focus of a presentation.
>>
>> On Fri, Dec 5, 2014 at 2:44 AM, Julian Rohrhuber <
>> julian.rohrhuber_at_musikundmedien.net> wrote:
>>
>>>
>>> On 04.12.2014, at 13:04, bitrituals <hellodanhett_at_gmail.com> wrote:
>>>
>>> > I'm still torn on this. The openness and expressiveness of
>>> shared/projected code is the element that drew me into seeking out
>>> livecoded performance, and subsequently performing myself. However I still
>>> feel like in some instances I'm not enhancing anything by exposing the code
>>> to the audience, although I suppose it's a little different for someone
>>> working just on the visual side.
>>> >
>>> > In some contexts it might even be a negative thing: if I'm livecoding
>>> visuals at a chiptune night for example, the audience aren't expecting a
>>> mash of code constantly overlaid on top of visuals, and would potentially
>>> assume there's something wrong! I was asked "why" with regard to the
>>> exposed code quite a few times at SuperByte recently, which was quite
>>> interesting I thought.
>>>
>>> Part of the problem might be the one-dimensional stage structure. If you
>>> have several projections in a room, you don't have to overlay code and its
>>> result.
>>>
>>>
>>> --
>>>
>>> Read the whole topic here: livecode:
>>> http://lurk.org/r/topic/4s86Rr9ZbfM72QlK2skEWF
>>>
>>> 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/1Fz1tKXtH6dqUP3oSYrA4E
>
> 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/21jl5xpVYF8oyn7mDIlRTa
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Fri Dec 05 2014 - 21:12:33 GMT