On Tue, 2004-07-20 at 01:39, alex wrote:
> There's still a couple of weeks left of the placard festival, maybe we
> should make a live coding placard session before its over? Linked via
> the Internet, with toplap-ratified video streams of our desktops. More
> info at http://placard7.ath.cx/
not sure I have the technology to do this, but I'm up for more
> > I dunno much about it (and would have to get time off work, which might
> > be tricky then) - really got the live performance bug now though so....
>
> The runme/dorkbot citycamp is 25/26/27 august in Aarhus, Denmark. It'll
> be a nice three days of workshops, presentations and performances.
ok, definately gonna try to make it to this, free accommodation would
definately help if it's at all possible...
> > I find the keyboard/mouse combination pretty useless for expression
> > personally, although I am stuck with it. I also think they make it
> > difficult to express process to an audience. I'm really interested in
> > moving code away from text (or boxes and wires) and into more immediate
> > forms.
>
> On the other hand I think text has some advantages that other forms
> might not. Text can be startlingly evocative, and have a rhythm and
> structure that relates well with music. It can be as precise or vague
> as you like, and the different extremes may be traversed with the
> introduction or omission of a single word.
yeah, I change my opinion a lot on this subject - I like the idea of
trying to look at programming in different ways, but when it comes down
to it I won't let go of my text editor... (endured a spate of UML
flirtation from managment a few years ago at work, and got all precious
about text)
> But yes, as far as writing text and in particular code is concerned, it
> is rather slow. I'm a really slow writer. The Perl language is a lot
> faster than many computer languages to use, but even so, typing an
> algorithm to make a rhythm can be a lot slower than hitting it out a
> drum. However by writing that text you're invoking actions that are
> much faster than a drummer.
>
> One way of looking at it is that writing code is an extremely fast form
> of expression, it just has a lot of latency!
I think at the very least we need to come up with some good languages
for live programming - maybe even design one for the purpose.
> > I have some embryonic ideas of a system where you would set up chain
> > reactions with big primary coloured lego blocks (a bit like a build your
> > own mr driller level):
> > http://digilander.libero.it/calimerosegg/gallery/gbadvance/mrdrill2.gif
> >
> > Would such a thing still be code? What does "code" mean? A turing
> > complete language?
>
> I read somewhere recently (probably wikipedia) that turing complete
> computers are impossible to build because they require infinite memory.
> In any case, turing completeness seems an arbitrary constraint.
it's the idea that if you can use a machine to duplicate the properties
of a turing machine (which is a universal computer) even given infinite
memory and time - it can be used to create any other machine - which is
nice, and important somehow.
Cellular automata can be made into turing machines (glider guns can be
made into logic gates etc...) Most programming languages obviously, but
not languages like HTML, and probably not my melodic lsystems.
> I think our earlier discussions led us to realise that it is probably
> not possible to strictly define the scope of toplap code. So we have to
> content ourselves with defining live coding as working closely with the
> composition of the music, rather than being almost completely abstracted
> away from it by consumer software.
I'm happy with this definition, as it's closer to the point than going
off down the computer science route. I think there is a continuum of
interface between the knobs and sliders of ableton live and the code we
are using - the fact we seem to need to do this highlights a shortcoming
of accepted ideas in GUI land maybe.
more waffle,
cheers,
dave
Received on Wed Jul 21 2004 - 23:59:16 BST
