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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
