lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Isolated durations in music sequences now stand for unpitched notes


From: dak
Subject: Re: Isolated durations in music sequences now stand for unpitched notes (issue 22120043)
Date: Tue, 12 Nov 2013 10:23:57 +0000

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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]