Root note accidentals conflicts with added accidentals

[no-chris]

From https://momo-chords.miklosdanka.com/

I cannot create the following chords:

• Ab9 (A with minor 9) => parsed as A flat with major 9
• Ab13 (A with minor 13) => parsed as A flat with minor 13
• C#11 (C with sharpened 11) => parsed as C# with eleventh

Is there a way to get those chords correctly parsed?

For exemple

• C/11 => is parsed as Cadd11
• but C/#11 => is an invalid chord

Thanks a lot

[mdanka]

Hey @no-chris! Thanks for flagging these.

Hmm. Which one is the standard interpretation? If both interpretations for Ab9 happen in practice, then we cannot differentiate using a computer program, we have to require a different shape. So I would have Ab9 parse to the more frequent interpretation. Every time I saw Ab9 somewhere, it referred to Ab with 9 and 7 added.

However, you can also write AMb9 if you want to add explicitly an A major with b9 added. Would that work for you?

[mdanka]

Re your second point: I think Cadd11 makes sense, but you don't have to add an #11 since it's parsed like that anyway. So you can write C#11 to get the chord you want.

You can try these here: https://momo-chords.miklosdanka.com/

[no-chris]

So if I write C#11 I get C# with an added 11. I would like to get a C with a sharpened 11.

If I write C##11 I get a C# with a sharpened 11. Close ;)

Instead of making a choice upfront on the most frequent interpretation a way to solve it could be to come up with a syntax that allow disambiguation of accidentals. What I posted is just an example of some issues we will always get because of the way accidentals are added:

• after the root note
• before the added notes So at some point you'll always get conflicts, even if not in the listed examples of my first message.

A way to do that could be to allow the "/" character to separate root note from added notes

• C/#11 would yield C with sharpened 11th
• C#11 would yield C# with perfect 11th
• A/b13 would yield A with minor 13th
• Ab13 would yield Ab with major 13th

What do you think ?

[mdanka]

You can write CM#11 to get a C Major with a sharpened 11.

Instead of making a choice upfront on the most frequent interpretation a way to solve it could be to come up with a syntax that allow disambiguation of accidentals. One goal of the library was to be able to parse the most common formats people write. For example, if I take a guitar tab online, it should get parsed. So I would still want the library to handle these cases.

I do like the idea of adding disambiguating syntax in addition to what we have. Doesn't adding M like I described do that though? If I write M instead of your / it seems to work fine.

Do you think having / would be a more friendly syntax? I'd be open to supporting it. (It might require some code change since / was so far only denoting the bass note, for example D/F#.)

Thanks for all the comments, I think these are useful discussions!

[no-chris]

After doing a bit of research I've stumble upon this kind of syntax in some lead sheets:

• Bb(b9)

Instead of M it seems that a lot of people use the 7th, since it is implied by the 9/11/13 it does not hurt to add it explicitly: Bb7b9. But it still feels like a hack and make the chord seems more complex than they really are Disambiguation is also often achieved at rendering time since added notes are most of the times written as exponents, but this does not help us here.

Speaking of M:

• It actually means that the 7th is a major 7th, instead of being a minor 7th by default. I've never seen this letter used for any other purpose (it might exist though)
• again it feels like a hack and is rendered as maj which seems a bit pointless since all chords are major by default until proven otherwise
• By playing with the demo I might have found another possible improvement regarding M:

C7 yields:

• Seventh: Seventh when it could be Seventh: minorSeventh

CM7 yields:

• Seventh: Seventh when it could be Seventh: majorSeventh

CmM7 yields:

• Quality: MinorMajor => should be Quality: Minor
• Seventh: Seventh => sould be Seventh: majorSeventh since the M refers to the 7th and not the chord itself

[mdanka]

1.

I was checking wikipedia, they write this:

Alterations from the natural diatonic chords can be specified as C9♯11 ... etc.

So from this it looks like that #11 does not imply 7 (or 9), and you have to add it explicitly.

2.

Regarding Bb9 and B7b9: again from the same wikipedia article, it looks like b9 doesn't really make sense unless one uses a half-diminished or diminished chord.

3.

I checked out another site, and they also parse C#11 as this library does: https://jguitar.com/chordsearch?chordsearch=C%2311&labels=none

They also do use CM#11 to denote a major chord: https://jguitar.com/chordsearch?chordsearch=CM%2311&labels=none

4.

If I remember correctly, the library uses things like Quality: MinorMajor because otherwise parsing becomes ambiguous in certain cases (see the test cases). So here Quality doesn't represent the actual "chord quality" but more like "the symbol around the place of quality in the chord". Though I'd note that these are called minor-major chords.

5.

again it feels like a hack and is rendered as maj which seems a bit pointless since all chords are major by default until proven otherwise

That's not very nice... maybe the right default here would be "M" as well? Though that would change how major 7th chords are rendered...

I could say that since this is quite a niche chord set, maybe we can accept the maj rendering.

6.

I like the concept of having minor and major 7ths in the library. But note that there also has to be minor and major 9ths. These have lots of implications down the line. We can try to adapt the library, but these suggestions only work if it is possible to implement them in such a way that all the unit tests pass. My experience was that that turned out to be quite hard. Hence the current system.

---

What do you feel would be an acceptable solution for you? Is there something that the library can support with the current structure? Or is it unusable for you unless we try to do some major change regarding the representations?

[no-chris]

First thanks a lot for you detailed reply and sorry for being this late (!) on mine.

1.

True from this quote. But then shall we expect everyone to know that C11 imply 9 and C#11 does not ?

2.

Well, dunno about this article. But browse the real book and you'll see plenty of b9 ;-)

4.

Indeed. But we have also another issue. If you copy/paste AmM7 in https://momo-chords.miklosdanka.com/ you get the correct parsing. Now try typing the same chord letter by letter and you'll get an Exception because of undefined here: https://github.com/mdanka/momo-chords/blob/b22e162431a2c9bcb5d04b940d92157124863adb/src/chordParser.ts#L212

As well as if you try A+M for example. Basic fix is to set {} instead of undefined but is it the correct fix or are we just silencing a deeper issue? In any case it should definitely not throw ;-) I can submit a PR but I'm not sure what the fix should be.

5.

Not sure what to think anymore :-) For me the Major symbol is only here to denote the major seventh, following rule 2 here: https://en.wikipedia.org/wiki/Chord_names_and_symbols_(popular_music)#Rules_to_decode_chord_names_and_symbols

So if I want to render Maj only for major 7th I don't think I have an option with the current setup, which could be a blocker for me.

Bb with b9 is not a niche chord set at all. Again, you can check the real book. Even less niche is C#9, that we would also need to write CM#9, which is IMHO less readable than C(#9), although that's just personal of course. This book also advocate the use of parenthesis (also with "MA" for major chords, I'm shooting myself in the foot I know that ;-) Also another take here: http://www.chordnamer.uk/more.shtml

The topic is so vast and complex that a way out of it could be to come up with some kind of opinionated guiding principles, a mix of above references for example, that would allow to make some decisions in those cases.

6.

Might try to come up with something, good that you have the unit tests. We could make them more complete by adding also the parsed chord form to every chord name checked. Of course we cannot do that manually but we could generate it so we catch any regression from the current setup, that would be considered as "correct" until proven otherwise.