Re: 2.16 release candidate 3 imminent

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:

>         
>     that all articulation events will be pulled out of NoteEvents or
>         
>     RestEvents and broadcast at the iterator level.
>         
>
>     There is such a thing as a chord articulation.
>     
>     
>
> Why couldn't this distinction be captured via a different event name?
> ChordArticulationEvent versus ArticulationEvent, for example.

Where would be the point?

> What would really help are some before/after examples (ly code and/or
> music streams and/or brief text like "before the patch, you could not
> do X, after, you can" or "this patch will allow me to experiment with
> implementing X") would help a great deal.  As if it were going into
> the Change Log, for example.

It's a bit hard since the whole design (perfected by the
rhythmic-music-event) was intended to make no user-visible difference.
The music expression has just become predictable.  You get an EventChord
iff < ... > has been in the input.  You get articulations on NoteEvent
for pitch-postevent regardless whether or not this is part of a chord.

If you use \displayMusic on something that you might want to put into a
chord, you don't get wrong input.  Tacking < > around a construct does
not change the structure of its inside.  It is not necessary to tack < >
around a construct to make a \tweak work (which is a user-visible
change).

You can use #{ #} for constructing material that ends up _inside_ of a
chord.  Something like
\displayLilyMusic < \displayLilyMusic ##{ c-. #}>
does not go up in flames but just does what one would expect.

It is just a whole lot of tiny annoyances and exceptions that are gone.

And, uh, footnotes with optional arguments might not have worked inside
of a chord previously.  Oopsie.

-- 
David Kastrup