"[email protected]" <[email protected]> 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
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
