Re: 13th chord?

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2017-02-25 23:08 GMT+01:00 David Kastrup <address@hidden>:
>> Rob Torop <address@hidden> 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