On 5/29/06, Han-Wen Nienhuys <address@hidden> wrote:
Erik Sandberg schreef:
> One way to achieve this change would be to provide a music type
Event, which
> wraps around a stream event and reports it, and to let the elements of
> EventChord be a list of stream events instead of music (which of
course means
> that EventChord's 'elements will be renamed to 'events or similar).
This
> change would make it more clear that the iteration process is the
process of
> assigning stream events to contexts.
This sounds very good, but I'm worrying about chord syntax, eg.
<c-\tag #'bla -. >
where NoteEvents have Event children (which again may nest). Does that
cause problems in a model where Events and StreamEvents are merged, and
different from Music?
That phenomenon already exists (a stream event can contain nested
music sometimes). With the new design, the StreamEvents will instead
contain other StreamEvents, so AFAICS the badness is unchanged from
the current state (and still, no event is ever sent twice). BTW, I
don't think there are any technical problems with nested events, only
philosophical/pedagogical problems (e.g.: is the music stream a
suitable format in general for music representation?)
Your example does however illustrate a different problem: There will
have to be some kind of distinction between music functions that
return music and stream events, respectively. One way could be to let
the parser do event->music type conversion implicitly when needed (so
it would be OK for music functions to return stream events where music
is expected, but not the other way around).