Re: Added ninth chord (symbol)

[Thomas Morley]

Regrettable, nested quoting is messed up :(
Anyway, maybe of some help though:

2016-04-30 8:56 GMT+02:00 Brett Duncan <address@hidden>:
>  On 30/04/2016 3:24 pm, address@hidden wrote:
>
> On Sat, 30 Apr 2016, Brett Duncan wrote:
>
>       I coded g2:5.9 in chordmode and got G9, which isn't the right
>       chord. I'm pursuing pop-chords.ly.

g2:5.9 is not correct. See the putput from the following code listing
some (all?) possibilities to _input_ the correct chord.

tst = {
  \chordmode {
   \set additionalPitchPrefix = "add"
   c:1.3.5.9
   c:3.5.9
   c:5.9 %% not correct !
   c:9^7
  }
  \notemode {
    <c' e' g' d''>
  }
}
<<
  \new Staff \tst
  \new ChordNames \tst
>>

I often put the chords in a Staff-context to check whether I coded
them correctly. More below.

> As Matthew said, you will need to override how the chord name is displayed,
> but this (or Matthew's suggestion) at least constructs a chord with the
> right notes.
>
> We should probably step back and clarify what seems to be the real issue
> every time someone asks about chord mode:
>
> Chord mode is completely separate from typesetting chord names.

Indeed.
We have different input-modes:
notemode (the default, thus rarely stated explicitely)
chordmode
figuremode
drummode

To illustrate, look at the output of:

\chordmode {
  c4:1 c:1 g:1 g:1
  a:1 a:1 g2:1
  f4:1 f:1 e:1 e:1
  d2:1 c:1
}

Granted, pretty pointless to do it this way, but valid code.

> "Chord mode" is chord *input* mode.  When you enter a chord with chord
> mode, it is immediately translated into a set of notes, and whatever code
> you used to enter it is forgotten.  Then if you are typesetting chord
> names, the chord names are determined by analysing that set of notes, not
> by referring back to the forgotten input code. [*]

Indeed.
It's done this way to gain the possibility to get different output
from the same source.
To illustrate:

mus = {
  \chordmode { c,1 }
  \notemode { <c e g> }
}

 <<
  \new ChordNames \mus
  \new FretBoards \mus
  \new Staff { \clef "G_8" \mus }
 >>

> I  agree with you about clarifying what the actual issue is at the outset.
>
>  I not sure that chord mode and the ChordNames context are as completely
> separate as you suggest, but IMO that's not really the issue. The problem
> lies in the fact that the default (Ignatzek) chord names are typically okay
> for only the simplest chords. The moment a user tries to input something
> more "complex" (not that an added ninth is particularly complex), what is
> generated is not what the user is after. I've seen plenty of messages on
> this list over the last decade or so complaining about this very fact.

Well, two problems.
(1) Like yourself I've seen a plethora of requests to write
chord-names in a certain way over the years.
Though, there is no general consense how to do it. Everyone wants it
(a little) different.
(2) LilyPond provides methods to get the desired output: via
exceptions or the already mentioned pop-chords-snippet
http://lsr.di.unimi.it/LSR/Item?id=750
and derivates from it.

Though, if you aim at an entirely different style like Brandt-Römer,
those methods are pretty tedious.

Right now there's at first a selection of pitches worth being
displayed in a chord-name.
To give an trivial example:
A simple major chord with tonic c is displayed: C and ofcourse not C ¹ ³ ⁵

Than a markup is created relying on those pitches, following the rules from
Klaus Ignatzek,  Die Jazzmethode fuer Klavier 1
(At least it's claimed, I don't own the book and can't check)

The problem is that some naming-styles (like Brandt-Römer) would not
only require different rules for creating the markup, but also the
selection of pitches is different.

It's a major task to make LilyPond flexible enough for this.
I already tried it repeatedly, but with no convincing result...

> I suspect many have done the same as me - created my own file of exceptions,
> added to it over time as need, and included it as a matter of routine. Which
> is fine for me and others doing the same, but leaves the unexpected Ignatzek
> defaults as an unhappy surprise for new users.


Well, the ignatzek-style chord-names _are_ a valid possibility.
We also used to have banter-style chord-names, which are really
strange, imho. Though they are broken nowadays and nobody requested
them for a long time.

The main problem is the lack of flexibility...

Cheers,
  Harm