Some more thoughts about the chord issue: I agree that it sounds somewhat icky to have repetition not extend to chords, in particular when having a music function with a body like #{ #music 4 4. 8 #} and calling it with either \rhythm c or \rhythm <c e>, it will be quite a nuisance that the first works and the second doesn't.
Now if we want to have this to hold for chords as well, we have to make sure we don't get into trouble with functions or contexts expecting to deal with pure rhythms when chords creep in unasked for. One way to do that is to provide a cleanup function that just removes pitches and collapses chords. That does not help with Pitch_squash_engraver: Pitch_squash_engraver also needs to reduce rhythms to a single notehead. If you take a look at the output of \new RhythmicStaff <c e>1 this just won't do. It may well be argued that Pitch_squash_engraver should at least remove duplicate noteheads with identical properties: \new RhythmicStaff << e1 \\ c >> arguably could display two noteheads but paradoxically doesn't, while using a chord delivers two. So the problem is that having a duration also work on a chord would require us fixing quite a few things elsewhere: this is less robust than explicitly calling functions for replacements and rerhythming. It still would not be fun in connection with TabStaff, not repeating string numbers and stuff, and such repetition is really not feasible. Of course the problem is that we have to make a decision what to support: a) we don't commit ourselves either way: it is undefined what a pure duration after an intervening chord will do. b) just single pitches, no chords: that's what this patch proposes. c) also chords: this patch needs more work, supporting code must be written, Pitch_squash_engraver has to be changed etc etc. The problem is that with both options b) and c), we'll soonish have music depending on this behavior. I'm leaning towards a): tell people not to rely on particular behavior after a chord for now. https://codereview.appspot.com/22120043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel