Hey Alex, All,
I started this as a personal reply, but I suppose it is the start of a
general discussion as well.
I couldn't help but notice your PhD transfer report that you use Turing
completeness as requirement on livecoding languages. 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?*
A few months ago I created the livecoding language I called the
"context-free music language" (
http://wiki.github.com/rndmcnlly/cfml/).
While it is certainly implemented inside of Turing-complete Scheme, it could
be easily made to have some surface syntax which strictly enforced the
limited nature in some parser. In making CFML, I was expecting to be find
all sorts of limitations because of lack of parameters, but inside I found
some interesting new practices. Because I was guaranteed that individual
patterns were context free, it became much more reasonable to provide and
regularly use a functional combinator library (similar to Andrew's
temporal-join and temporal-append functions in Impromptu).
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. 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. What is seems to come down to is
that, between edits when your program is held constant, you know your
algorithm comes form from some particular language (with whatever
constraints that implies).
In other thinking, I was trying to figure out how I might make a "regular
music language" interesting enough to use, and the pattern combinators you
have in Petrol are very interesting. I can imagine some language which has
several of the combinators from petrol but also includes simple
non-deterministic sequencing. The result would be a livecoding language that
is "piecewise-regular" with respect to time/edits. At any one time, the
program that is running is some finite automaton that is spewing out
musical-event-literals or time-skip events.
While knowing that, at any one time, the running program is some ugly
regular expression compiled from your high level code might not be that
useful compositionally, it does suggests the basis for a kind of music
visualization that is more inherently honest and illustrative than the
currently popular flashing lights approach. In livecoding the audience is
looking at your high level code, though with current audiences, they are not
likely to be able to follow much of it. However, they do have a major clue
as to the meaning/semantics of your code in the form of the current music
that is being played. There is a pretty big gap between the high level code
and the ground musical events though. 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).
On Sat, Mar 6, 2010 at 1:28 PM, alex <alex_at_lurk.org> wrote:
> Hi all,
>
> The survey I did ages ago was secretly about live coding creativity
> and ended up being written up in a conference paper (iccc-x) in
> shortened form. A fuller version is chapter 6 of this report:
> http://doc.gold.ac.uk/~ma503am/writing/transfer.pdf<http://doc.gold.ac.uk/%7Ema503am/writing/transfer.pdf>
>
> Thanks again to all who took part.
>
> I also wrote a paper on my pattern library for ICMC:
> http://doc.gold.ac.uk/~ma503am/writing/icmc10/petrol-draft.pdf<http://doc.gold.ac.uk/%7Ema503am/writing/icmc10/petrol-draft.pdf>
>
> I heard that reviews from ICMC are not likely to be detailed this year
> so any feedback much appreciated. It does need a fair amount of work,
> in particular more musical examples, although space is short...
>
> Cheerio,
>
> alex
>
> --
> http://yaxu.org/
>
Received on Sun Mar 07 2010 - 06:45:28 GMT