On Sun, 24 Oct 2004 16:22:26 +0100 (BST), Marcel Gonzalez Corso wrote
> > >> Pair this with concurrency, and it allows you to
> > follow parallel
> > >> flows
> > >
> > > I don't think it's possible for my brain to do
> > that!
> >
> > If you can read code through control flow, then it's
> > possible to
> > understand
> > at least one flow, if the language/system lends
> > itself to that.
> > Parallel flow is
> > harder, but if you can parse a band into component
> > parallel members,
> > then
> > maybe it's possible and interesting to do so with
> > code.
> >
>
> What about coloring the code line wich is being
> executed differently? Like many debuggers do...
> And do that for all the threads (or scripts) that are
> playing? Arrange them in the screen(s).
> The viewer/listener could try to relate one sound
> pattern to one of the threads?
>
> To be readable i guess it would be necessary to
> sleep(some time) on every codeline. bluerg!
yeah, on the whole, I think this would be a useful addition to live coding
environments, but it's hard. In my music app for instance, there is a lot of
seperation between the sequencer and the interface that would make this
difficult, as they are different processes - you could do it, but getting the
timing right would be very hard...
but this is just a technical issue.
in some ways it just doesn't make sense - in fluxus if you stepped through the
code it wouldn't really tell you that much about what was going on, it's not
really a linear process that you'd make much sense of. most of the scripts in
fluxus are no longer than 10 or 20 lines anyway, so you'd just get the
recursive looping a couple of lines and a slideshow framerate. in this case
it's more informative to read the small amount of code.
OTOH, another advantage to the virtual machine approach is the ability to view
the contents of memory and registers as the code is running, this is as
important to understanding the process as view the code IMHO, and in a very
small (virtual) processor, quite simple to display and understand.
this is why I like the idea of editing code "inside" the machine a line at a
time as it's running, rather than updating the code in chunks that get
uploaded to replace a running process. doing in-processor livecoding has a lot
of disadvantages, being much more error prone and there are a lot of higher
level things you couldn't do easily with a small instruction set at a slow
speed, but it certainly makes the process somewhat more direct.
another idea is to look at universal machines that could be programmed
visually so that the description, process and the execution are the same -
conway's "life" springs to mind - you could have pixels that trigger sounds,
and build glider guns to fire patterns at them.... you can build the basic
logic gates out of glider guns and glider "eaters" I believe.
there is also Toshio Iwai's music insects, which could be seen as live
programming, now I come to think of it:
http://ns05.iamas.ac.jp/~iwai/artworks/music_insects.html
enough monday morning "just got into work" rambling... :)
dave
Received on Mon Oct 25 2004 - 09:40:33 BST