music events vs stream events

[Erik Sandberg]

Hi,

During my current parser work, my way of viewing the Music class is changing; 
the difference between events and non-events tends to grow over time. Here's 
a couple of observations:

- on the translator side, the only immutable properties that are read are, 
with few exceptions, name and types. Those two properties should really be 
handled by dispatchers.
- If Translator::try_music will be called through dispatchers, then all 
translators will need to extract music events from stream events, which feels 
like an unnecessary extra step.
- There will probably be a difference between events and non-events in the 
parser: Non-events will produce syntax rules, while the parser will create 
events directly.
- The music-class of non-events is seldom used, and the semantics of 
music-class for non-events is a bit unclear to me.
- I don't see a clear semantical difference between music event and stream 
event.

While most of these are small issues, the sum makes me conclude that music 
events are closer to stream events than non-event music. It would therefore 
feel natural to use stream events to represent music events.

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.

There are of course some problems; for example, length-callback etc. must be 
handled somehow. I think the best way of doing length-callback is to wrap the 
event in a music whose iterator sets the event's length properly.

If this sounds good, I can place this on my todo, after finishing parser work 
and music streams.

-- 
Erik