Re: Issue 2229 in lilypond: Patch: Broadcast articulations not in EventChord

[lilypond]

Updates:
        Status: Started

Comment #6 on issue 2229 by address@hidden: 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.