Closed karlding closed 6 months ago
Hello Karl,
Thanks for reporting this issue.
Your are correct, the name of a chord should not be mangled if unknown. Fixed.
Generalising the add
chords needs a rewrite of the chord-parsing so for now I just added the add4
and add11
qualities.
The fixes are in the SwiftlyChordUtilities
package and I’ve updated Chord Provider
to use this new version.
If any other issues, just let me know!
(I'm not sure if this is more of an issue with the
SwiftlyChordUtilities
dependency or Chord Provider itself, so feel free to move the issue)I have a chordpro file which contains a
Gadd4
chord (also known asGadd11
).Since Chord Provider doesn't recognize this chord, I defined a chord chart + fingering for it:
This rendered as:
in both the display and PDF output which was a surprise, since I expected this to display the chord name I wrote.
A quick fix might be just to add support for
add4
chords. Looking at the wayadd9
is supported inSwiftlyChordUtilities
, it appears like you explicitly added a case forChord.Quality
to coveraddNine
. Should there also be anaddFour
/addEleven
?Although thinking about this some more,
add
chords are just the major triad with an "added" interval above the root, so theoretically it would be possible to construct arbitraryadd
chords with intervals over the entire octave. However, the number of such chords is bounded if we assume we’re naming chords by “normalizing” the added interval within the octave (soadd11
would be written asadd4
). So perhaps the path forward is to generalizeadd
to allow for arbitrary intervals?It seems reasonable that the chord database may not be exhaustive, but my main issue is that the name gets mangled in the display (and also PDF output). For chords that aren't recognized, could the original name be kept as-is instead of mangling the name?