On 7 March 2010 06:44, Adam Smith <adam_at_adamsmith.as> wrote:
> I couldn't help but notice your PhD transfer report that you use Turing
> completeness as requirement on livecoding languages.
Yes I used it as a quick and convenient definition. Certainly not
authoritative outside of the report itself.
> I can understand the
> move to a more rigorous definition of livecoding languages to exclude things
> like pressing merely buttons on a groovebox or rewiring devices in Reason on
> the fly, but, and here's my question, how important is the actual
> Turing-completeness aspect?
I'm not totally sure. This issue came up before in October (subject:
IXI lang), although we didn't go into detail and I think everyone
disagreed with me.
At the moment I don't think it is important. A Turing complete
language certainly seems a prototypical medium for live coding. But
why make the constraint on the language and not the use of it?
Perhaps that is a better place to start, not looking at what is
possible but what is done; the making of symbolic abstractions for
example.
> A few months ago I created the livecoding language I called the
> "context-free music language" (http://wiki.github.com/rndmcnlly/cfml/).
Nice! Yes this is a very good counterexample, I wouldn't claim this
wasn't a live coding language.
> Working within a context-free language made it clear that distinctions
> between Turing completeness and context-freeness become much less important
> when you can edit the code while it runs.
A good point.
> In terms of Turing machines, the
> ability to edit the tape at run-time busts you into super-Turing territory
> right away, even if your surface syntax is technically just regular
> expressions or something else limited.
Or indeed just editing a plain sequence of notes. Actually I think
symbolic computation is involved even when improvising music on a
piano. Why wouldn't it? Notes are clearly symbols. The argument
isn't that live coding is something completely different. In my view
playing music always involves computation married with spatial
exploration and reasoning. It's just that when you play the piano,
some of the spatial exploration is made explicit, whereas with live
coding some of the computation is made explicit.
>From that perspective, Turing completeness seems useful, because
notionally any computation can be represented. But you're right,
context free language is powerful enough. I've certainly done many
`live coding' performances where I've just tweaked constants in
pre-prepared scripts... I think the open-endedness of live coding
with general purpose languages can at times make the use of it rather
conservative.
So basically I'm confused...
> Perhaps a visualization of your code
> that is guaranteed to use no more than a regular expression (visualized with
> state-edge graphs and a highlighted current state) or context-free grammar
> (visualized with a tree and a highlighted path of active nodes) would
> provide a middle ground that entices the audience to both notice low-level
> regularities in the music and bootstrap understanding of your high-level
> code. Across edits, it would also serve to visualize the difference between
> edits that merely tweak a parameter and those that radically change the
> generation space (despite both only involving a two-character change,
> perhaps).
This sounds great!
cheers
alex
--
http://yaxu.org/
Received on Sun Mar 07 2010 - 20:44:53 GMT