On Sun, 26 Feb 2017, Wols Lists wrote:
> I'm guessing lily is taking *in* his request for "C 13", converting it
> into the chord, and then converting that chord *back* into what it
> thinks is called "C 9 13". With the result that lily's output does *not*
> match the user's input. Frustrating!
Okay, I think I see the issue - it's the same problem everybody has with
chord mode and ChordNames, which is that those two things are completely
separate from each other despite the usual use case treating them as a
single entity.
\chordmode { c:13 } turns into <c' e' g' bes' d'' a''>
\new ChordNames { <c' e' g' bes' d'' a''> } prints "C9 13"
I agree it looks like a bug, but because of the separation between chord
mode and ChordNames, each is going to point the finger at the other as
being at fault, because each one is using its own rules which taken
independently seem sensible. The real solution would be a thing like
ChordNames that is actally a specialized markup mode and just *prints
whatever is typed dammit*, with minimal formatting transformations
(perhaps automatically putting numbers in superscript, and that's about
all), instead of trying to convert to "music" and back.
Probably the easiest thing to do is use an override on printing the chord,
and just ignore the fact that the notes are wrong internally (which
doesn't matter as long as the chord mode input is only used for
ChordNames). Like so:
chExceptionMusic = {
<c e g bes d' a'>1-\markup { \super "13" }
}
chExceptions = #( append
( sequential-music-to-chord-exceptions chExceptionMusic #t)
ignatzekExceptions)
\new ChordNames {
\set chordNameExceptions = #chExceptions
\chordmode { c:13 }
}
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
