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

[lilypond]

Comment #20 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

The last patch marks everything that can be an "articulation", namely an  
event attached to a single note inside of a chord, in a separate music  
type.  The problem I need to address is that currently, c-. is equivalent  
to <c>-., namely an articulation on a single-note chord, which is different  
from <c-.>.  We now have the ability of letting music functions operate  
_inside_ of a chord.  A music function \fun with a single music argument  
can be called as <\fun c-.> and then it gets a single non-chord note event  
with an articulation.  If it is called as \fun c-. outside of a chord, it  
gets a chord event containing a note-event c and a detached articulation .  
for the whole chord.

Maintaining this context-dependent distinction of the call is not feasible  
for anything but trivial cases.

I have experimented with several things in the front end creating the music  
expressions.  The results add complexity and make things less predictable  
while providing compatibility for perhaps 80% of all programmatic use cases.

So I don't want to do a half-baked job here.  And that means that the  
equivalence
c-. <=> <c>-. should not be implemented in the parser.  It should be  
established by the engravers, by having the EventChord engraver switch its  
children to "engrave as per-note articulation" mode, when they would let  
their articulations be engraved in "per-chord articulation" mode when  
outside of an EventChord (something which can currently not happen).

This mechanism is not there at the moment.  You are discussing what kind of  
events should inherently be able of doing a per-note reaction, and which  
kind of event should automatically trigger per-chord mode.

And you say "But I don't know if this is really possible or not."  It is  
currently possible (more or less in a hardwired way), and my problem is  
providing a way to _keep_ this distinction _without_ requiring an  
EventChord wrapped around even single notes.  By implementing it at the  
engraver/iterator level rather than at they syntactic front end.

I want to get to a state where the question "how does the music expression  
c-. look in Scheme" is not answered with "it depends on whether we are  
inside a chord or not".

I want to have the music expression look the same.  Period.  The different  
behavior can then be established in the engravers.

Your comment addresses the question "what should be allowed as a per-note  
articulation".  That is not interesting to me right now: I just want to  
maintain the current behavior.  If the current behavior should be changed,  
the change would look different with the current code, and with the code  
after this issue passes.  Hopefully easier in the second case.  But my  
current problem is not "what should we do", but rather "how".  I don't know  
how to make engravers work differently with articulations inside of an  
EventChord rather than when encountered without such a wrapper.  That's  
where I need help.