music and events

[Erik Sandberg]

Hi,

I have been experimenting with creating stream events directly in the
parser. I have faced a couple of problems, and I found two possible
ways to go.

IIRC, the issue has been brought up before, and then the answer was
"why don't we wait until 3.0". However, I would find it useful to know
which solution to go for after 3.0, because it influences design
decisions in other areas.

My first conclusion is that the root of a music expression tree always
should be a Music object; it should never be a Stream_events. This is
because I want to avoid typing problems; we need lots of hair if
functions such as \tag has to accept both stream-events and music, so
in <c-\tag 'foo -.> we want to represent -. as a Music. But once -. is
Music, the articulations of a note stream-event will be a music list,
which is rather unclean IMHO (we don't want engravers to know about
music).

AFAICS, this leaves two possibilities. I think I have suggested
something similar before, but it's more clear in my head now:
1. Keep the current temporary solution as it is, only with minor
cleanups. This means that there is a Music::to_event method which
builds a new Stream_event object, based on the mutable_properties
list. We may make to_event more sophisticated, so it filters out some
properties that aren't relevant for stream events, and it can also
convert articulations to a stream-event list when copying the
mutable-property-alist.
2. Let each Music event contain a property 'event, containing the
stream event that corresponds to the return value of to_event in (1).
Music properties will be split into two (hopefully) disjoint classes,
music properties and stream-event properties; it will only be possible
to set stream-event properties in stream events. There will be a
get_event method, similar to get_length.
The main advantages with 2 are that we separate music properties from
stream-event properties, and that music gets simpler.
The big disadvantage is that stuff changes, which may break user
scheme code. A workaround is to let ly:set-music-property and
ly:music-property refer to event properties in the 'event whenever
typechecking suggests this; I think this solution preserves backward
compatibility.

I'd vote for 2 because I think it's cleaner.

--
Erik