Neil Puttock <n.puttock <at> gmail.com> writes: > > 2009/6/28 David Bobroff <bobroff <at> centrum.is>: > > When using 'extraNatural = ##f' key cancellations at key changes are not > > complete. Key signature elements which change between sharp and flat on the > > same note names are not canceled. > > > > Feature? > > Yes. It's deliberately set this way in the Key_engraver. >
After thinking a few months, and reading Kurt Stone's book, I am convinced that this is a design error. The logic for printing naturals on notes (check-pitch-against-signature) is re- implemented in Key_engraver::create_key. The implementations look consistent, but consistency is not appropriate here. On notes, we see the extra natural and the new accidental together, and the natural is very often removed. In key signatures, we see the naturals as a group and the new signature as a group, so the extra-ness of the natural is less obvious. The group of naturals, the key cancellation, is sometimes removed as a group. These two types of omissions are treated independently in everything I have read. Lilypond's incomplete key cancellation, demonstrated earlier in the thread, is *never* used. Therefore, extraNatural=##f as implemented must always be accompanied by either printKeyCancellation=##f, or a temporary restoration of extraNatural, for each key change. Solo piano music especially likes to use 'black' keys like des\major and cis \minor, where extraNatural=##f is very helpful for brevity, but complete key cancellations are also helpful when learning a new piece. So I leave the cancellations in place, toggle extraNatural whenever I remember it, and am embarrassed when I forget. Is there any reason that key cancellations should honor extraNatural=#f ? -- Keith P.S. I would be easily capable of this patch once I figure out git: four lines removed from Key_engraver, replaced with a comment that extraNatural is intentionally ignored, and the removal of the regression test key-signature- cancellation-extra-natural.ly, and down-grading of issue 1399 to a doc fix. _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
