This is a follow-up on a discussion from the issue tracker comments at <http://code.google.com/p/lilypond/issues/detail?id=185>,
where I suggested a kludgy fix for a favorite LilyPond pet peeve of mine. I am interested in making it less kludgy. As I am new to the LilyPond codebase, please bear with some ignorance. Some context: My original proposal <http://codereview.appspot.com/6495107> > Make RhythmicStaff show single notes for chords (issue 185) > > RhythmicStaff uses Pitch_squash_engraver to move all note heads to a > common vertical position. With chords, at least two problems arise: > > (1) As all notes from one chord collide now, so some of them used to > > be moved aside. Hence, for each chord, two adjacent note heads > would appear in the output. > > (2) For chords with dotted duration, Dot_column_engraver would put one > > dot per note head into a DotColumn, where they would be spaced > apart. So for every note in the chord, one separate dot would be > visible. > > Solve (1) by explicitly setting X-offset to 0 for squashed note heads > in the Pitch_squash_engraver. > > Solve (2) by replacing Dot_column_engraver with a new > Squashed_dot_column_engraver. This variant puts only at most one dot > per time step onto a DotColumn, and marks any further ones as > transparent. * d...@gnu.org comprehensibly suggested instead: > Wouldn't it make sense to let the Pitch_squash_engraver suicide all > duplicate grobs at a time step? It would actually be even better if it > could just kill the respective events before other engravers even get > to see them. Also it would seem that only duplicates in the same Voice > should be squashed. and later > Maybe we need an engraver listening to Stems and shooting all > NoteHeads except the first per stem. This should take place before > collision resolution. but I fail to find an exploitable connection between stems and chords. As far as I understand, Stems are grouped with note heads into NoteColumns by Rhythmic_column_engraver only, which operates at Voice level, hence too late. Judging from this engraver, it looks to me like one could implement a "Chord_thinout_engraver" at Voice level simply by acknowledging rhythmic_heads and killing all but the first per timestep. But I need this functionality at Staff level. (One could include such an engraver into all Voice contexts, but trigger it with a Staff-level property. Sounds kludgy again.) So far, the most viable route to me seems to make use of this > ...an acknowledger is called not just with a grob but also with the > originating engraver instance announcing the grob, and so one can > indeed figure out the originating context of an announcement _if_ the > grob is produced from a Voice-level engraver instance. to write a Staff-level "Chord_thinout_engraver" that still works per voice. Is that the way to go? Other ideas? Best regards, Johannes Rohrer _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel