Updates:
Status: Started
Comment #6 on issue 2229 by [email protected]: Patch: Broadcast articulations
not in EventChord
http://code.google.com/p/lilypond/issues/detail?id=2229
Hi Mike,
let me see whether I get this right. The iterator is the entity converting
a music event into a stream event and broadcasting the latter. So the
rhythmic-iterator would be responsible for "wild" rhythmic music events
(that currently can't occur since the parser wraps everything into
EventChord) and would dismantle their articulations, create a stream event
from the music event not containing articulations, and broadcast this
stream event as well as the stream events created from articulations.
When the EventChord iterator gets an EventChord music event, it would cater
for converting the contained rhythmic music events into stream events
containing articulation stream events, and broadcast those. The rhythmic
event iterator would never get to see any of that.
So correct me if I am wrong: if we applied your patch to the current
LilyPond, the Rhythmic event iterator should not get to see any action
except possibly on synthesized music (where naked rhythmic event chords
would have their articulations work like chord articulations rather than
chord constituent articulations).
If (after changing the parser not to put EventChord on unnecessarily) we at
one time decided that c-. should not be equivalent to <c>-. but to <c-.>,
then we would just need to change the rhythmic music iterator.
If I got the details right, this sounds like it would indeed be a cleaner
solution. Is there actually anything missing from your patch for doing the
whole job of this issue?
The one thing I worry about is that some other iterator might have first
rights on the music events. As you can easily guess, I have no clue in
this area.
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
