"m...@apollinemike.com" <m...@apollinemike.com> 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel