Re: [livecode] when is it live coding, when not?

From: Georg Essl <gessl_at_umich.edu>
Date: Tue, 13 Aug 2013 12:05:36 -0400

Just the word "coding" and "program" are complicated categories. It seems
to me that Konstantinos's notion of "indeterminancy" with respect to choice
(if statements, state dependent execution etc)) makes quite a bit of sense.
I think that, in connection with some kind of run-time execution may well
sensibly encapsulate a suitable large set of programming that can hold
visual and dataflow concepts along with more canonical forms of textural
coding.

However perhaps the word indeterminancy is not the best to use. After all
the state of a knob in a sequencer software is also undetermined and the
editor has a choice how to set it. It seems to me to be better to make
clear that the choice in question is an algorithmic one. Perhaps
"branching" is rather more it? A knob cannot take conditional paths of
execution based on state over time, whereas a program can. It seems to me
that a Turing machine is the essence of deterministic branching. The local
state determines (conditionally) the future state.

However that is a rather low level of describing programming. On the high
level heavy use of large code blocks, copy-paste, APIs etc are basically
standard practice and in fact linear concatenation without any branching
can (thanks to abstraction) lead to powerful outcomes, so I'm not sure how
much indeterminancy/branching helps demarcate here. Certainly some of the
heaviest coding I have done can have very few branching points (think a low
level audio or graphics engine). There the devil lies in the complexity of
the setting more than in the richness of the branching. Also with respect
to copy and paste, I have to admit that some of my heaviest coding session
include minimal novel coding from me, and plenty of trying to get code
working that others have gotten working before.

Still indeterminancy/branching does seem to be a good taxon to describe if
the overall environment is programmable, independent on the actual act of
coding on top.

As for liveness, to me that simply has to do with the degree of
interactivity of the programming process. I know that there is some
complication with regards to the word "live" as it also crosses over into
live performance, where a lot of practice is going on. Of course a "live"
programming environment is good for live performance but that does not mean
that live performance is required to use that liveness. A musical example
would be that a clarinet is a clarinet with all its performative
characteristics even if it never is used in a live concert, and while it
helps to understand live concerts and it shapes how clarinets are build,
the characteristics persist without that setting.

- G

On Mon, Aug 12, 2013 at 9:17 PM, Kassen <signal.automatique_at_gmail.com>wrote:

> On Sat, Aug 10, 2013 at 04:05:51PM +0200, alln4tural-list_at_gmx.net wrote:
> >
> > would that still be live coding?
> >
>
> I seem to remember that last time this topic was covered we ended up
> with a focus on "public reasoning".
>
> So; we could imagine a typed performance in SC that were so obfuscated
> and pre-prepared that it'd disqualify on both counts. We could also
> imagine somebody scripting a mp3 player (not sure whether iTunes in
> particular permits for that) based on some sort of input from the
> audience to somehow express something about track selection in DJ-sets
> based on audience feedback that we might count. I expect a disaster in
> that last case as that task is exceptionally hard even for people, and
> so I suspect algorithms written on the spot will fail, but that need
> not be a issue here.
>
> To me the term "livecoding" is not founded on how fluently the
> performances goes any more than playing the violin badly turns it into
> a guitar.
>
> Admittedly that perspective has a lot of very vague areas and
> potentially leaves lot up to the performer and audience; I think that
> need not be a bad thing at all.
>
> Yours,
> Kas.
>
>


-- 
-- 
Georg Essl
gessl_at_umich.edu
(734)-730-0791
Assistant Professor
Electrical Engineering & Computer Science and Music
University of Michigan
Received on Tue Aug 13 2013 - 16:06:35 BST

This archive was generated by hypermail 2.4.0 : Sun Aug 20 2023 - 16:02:23 BST