fre 2008-02-22 klockan 15:42 +0000 skrev Dave Griffiths:
> >
> > On Fri, 2008-02-22 at 10:22 +0000, Dave Griffiths wrote:
> >> > IMHO the audience is better off perceiving the music via the sound
> >> > rather than via the code though.
> >>
> >> To me, this highlights a problem with the code.
> >>
> >> One of the reasons I spent some time looking at forms of code which go
> >> beyond the static ascii page is to make it more connected with the 'end
> >> result'. I think it's important to find ways of presenting programming
> >> which are clear and readable by a lay audience (I know I'm in the
> >> minority
> >> with this view).
> >
> > I'd restate this problem as - how to define a language that is richly
> > expressive so it can be used to compose music, but does not need any
> > training to read.
> >
> > I think you manage this in al-jazari etc by
> > a) use metaphor in the syntax of the language -- robots, daisy chains,
> > thought bubbles etc. It's easy (and a joy) for a lay viewer to
> > understand registers, iteration, sequences, functions etc in these
> > terms. It's not that the language is 'intuitive', it's that they take
> > advantage of knowledge and understanding we have already have.
> >
> > b) using small alphabets, consisting of familiar icons, and not
> > combining them into words. This makes the language simple and easy to
> > grasp.
> >
> > And I agree this works very well, I think because it is so well done
> > that it can be appreciated as part of the music.
> >
> > I think though that b) is a big deal, that there is a place for pure
> > textual live coding and probably always will be.
> >
> >> I now think that this objective makes livecoding better for the
> >> performer
> >> too.
> >
> > I think there are pros/cons.
>
> Yes b) is a massive problem, especially in the light that I had to write a
> scheme based system for our recording the other night (sans audience), and
> I need to explore that for a bit I think.
>
> The main problem with b) is that it makes abstraction difficult. I need to
> rethink ways of doing this. Axioms for building on in a visual way - but
> it's hard to come up with anything approaching quote, atom, eq, cons, car,
> cdr and cond.
>
When I read this, I came to think of an article I read several years
ago about Japanese mobile phones, when text-messages was the New Thing.
Since the Japanese language contain so many signs, they can't fit them
all on a mobile-phone keyboard, so they had to cut them upp in
different patterns that appear throughout the signs. A dot in the
top-left corner, a horisontal line in the center, etc.
These patterns doesn't mean anything by them self, but if you combine
them like you combine clothings for a paper doll, you can create all
the complex Japanese signs.
Note, I read this a _very_ long time ago, and I don't think I can trust
the source so I might be very very wrong, but still, one could create a
graphical Forth-like language like this. (Dave: a betablocker for PacketForth? :-)
Hope I've made myself clear,
Gasten
Received on Sat Feb 23 2008 - 10:07:57 GMT