Re: Issue 2070 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.

[lilypond]

Comment #21 on issue 2070 by address@hidden: Patch: Don't wrap  
EventChord around rhythmic events by default.
http://code.google.com/p/lilypond/issues/detail?id=2070

Just a pedantic terminological thing: there isn't an EventChord engraver,  
just an EventChord iterator.  Iterators do different things than engravers  
- iterators comb through music events to figure out how to send events to  
engravers, and engravers receive events and do things with them.

If you want c-. to behave like <c>-. but not <c-.> in a context where  
rhythmic events are not necessarily wrapped by event chords, after line 49  
of event-chord-iterator.cc, you can do something like  
mus->set_property("containing-event-chord", get_music ()->self_scm()).   
Make sure to define the property in define-music-properties.scm.  Then,  
when you get to the new-fingering-engraver, you can test note_ev to see if  
it has something stashed in the property "containing-event-chord" defined.   
If not, that means that the note must be solo, in which case you can treat  
the articulation differently.

Another solution would be to create an ArticulationEvent in the  
simple-music-iterator if an event has an articulation array.  When an event  
hits this iterator, check to see if it has an articulation array.  If it  
does and does not have something set for "containing-event-chord", report  
an ArticulationEvent via report_event (you can construct this event through  
a Scheme callback).

The second option seems better than the first, as it won't require messing  
with the engravers - they'll receive the same information they did before.   
It's just that the iterator will create a new event.

I don't have time to test the patch this week, but hopefully that gives you  
food for thought for ways to move forward with it.