Thomas Morley <thomasmorle...@gmail.com> writes:
> 2017-02-25 23:08 GMT+01:00 David Kastrup <d...@gnu.org>:
>> Rob Torop <rob.to...@gmail.com> writes:
>>
>>> When I enter a 13th chord like this e:13, it renders with a 9 as well.
>>> I know a 13 chord officially contains the 9 and 11, and that lilypond
>>> by convention will omit the 11. But I don't really want to have the 9
>>> showing. Do I inadvertently have some setting on that is giving me
>>> this?
>>
>> Minimal example:
>>
>>
>>
>> The default chord printer is Ignatzek. No idea whether this would count
>> as a bug with the Ignatzek naming framework or not, and how the other
>> chord printers would behave in comparison.
>>
>> As a default, the mismatch between input and output seems weird.
>
>
> Well, we omit the 11 by purpose,
> See the comment in construct-chord-elements from chord-entry.scm and
> regtest chord-name-entry-11.ly.
Huh? Have you taken a look at the output?
> Also quoting "Standardized Chord Symbol Notation" by Brandt/Roemer in
> section "Dominant Thirteenths":
> "In accepted usage, the 9th is included but the 11th is omitted. Quite
> frequently the unaltered 5th is also left out."
>
> So no bug, but a design decision.
The problem is not with the conversion of the input to a chord but with
the conversion of a chord to a ChordName.
> To have the 11th included, one needs to explicitely state it:
>
> \chords { e:11.13 }
>
> If this is not done, the printing as E⁹ ¹¹ is ok, imho.
\chords { e:13 } is printed as E9 13 rather than E13 . So the question
is why the rationale for converting e:13 to chord notes differs from the
rationale converting the chord notes to a chord name.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
