[TECH] Keys and Enharmony - Glidias/gingkstep GitHub Wiki
This document covers some technical conventions with regards to key signatures and transposition for the Gingkstep application.
Current Limitations:
Enharmonic Caveats for song chord notes and keys
- For numeral chord notations, the feature for multiple consecutive flats or sharps for chords/notes (not yet available, but on the roadmap before phase 2) will be added with possibility to support up to (max) triple flat/sharp representations. (but from numeral chord notations, only).
- For phase 1, the displayed chord/note letters will still use the resolved white pianos keys whenever available however and not represent them as consecutively shown multiple sharps/flats. For some casual users (or perhaps most users?), this could actually be considered the ideal option.
- This may optionally (for phase 2 consideration only) (according to user device preference) result in chord letters with multiple flats or sharps shown accordingly due to double/triple flats/sharps being used to represent certain notes/chords. But again, how can this be a global setting instead of only something to show/notate on specific chords/notes within a given context?
- Likewise, other rather edge-case single sharp/flat keys signatures that resolve to a white piano key (eg. Cb, Fb, Cb, E#) aren't well supported at the moment when it comes to displaying the "correct" matching enharmonic symbol in relation to such key signatures/notes. Instead, the plain white key letter note is always displayed instead. This issue will be considered for phase 2 and may be considered under a completely different module and codebase.
- There will also be no consecutive enharmonic presentation resolution support for theoretical key signatures involving multiple consecutive flats or sharps for chords/notes . https://simple.wikipedia.org/wiki/Theoretical_key#:~:text=In%20music%20theory%2C%20theoretical%20keys,%2Dflats%20or%20double%2Dsharps . Again, supporting this seems rather impractical.
Enharmonic preferences for key signatures
This is the method I came up with to help determine enharmonic preference to use for respective key signatures (ie. the symbol sharp/flat to use on a staff to represent diatonic notes):
Major:
C : -
C#/Db : #/b
D: #
D#/Eb: #/b*
E: #
F: b
F#/Gb: #/b
G: #
G#/Ab: #/b*
A: #
A#/Bb: #/b*
B: #
- For major keys with root note on black piano keys, simply use matching sharp/flat symbol of key signature for preferred enharmonic.
- For major keys with root note on white piano keys (no sharps or flat symbols), run a whole step back (2 semitones) from it. If it falls on white key, sharp(#)s is used, but it falls on a black key, flat(b)s are used. (Actually, this means only F white key uses flats on key signature, though C can be considered a theoretical flat preference even though such a key signature has no accidentals)
*
Preferred enharmonic representation when resolved from relative minor white key.
Minor:
Cm: b
C#m/Dbm: #/b
Dm: b
D#m/Ebm: #/b
Em: #
Fm: b
F#m/Gbm: #/b
Gm: b
G#m/Abm: #/b
Am: -
A#m/Bbm: #/b
Bm: #
- Simply refer to the relative major equivalent's preferred enharmonic representation particularly for white keys.
- Alternatively, for black key minor notes, simply use matching sharp/flat symbol of current key signature for preferred enharmonic.
A disclaimer to take note of when it comes to current preferences/conventions... everything below is subjected to change.
Enharmonic symbol preferences for chord notes
For roman/numeral notation chords, the enharmonic symbol preference of it is used instead . (eg. bV
for preferred flat, #4
for preferred sharp). For the convention of note letters in relation to a given key signature, the following conventions are used.
- Diatonic notes follows the key signature's preferred enharmonic.
- Non-diatonic notes run enharmonic symbols opposite of that (eg. a key signature of F major (1 flat on staff) will use G# for it's minor 3rd.
Enharmonic preferences/conventions during modulation over transposed keys
Currently, when it comes to transposed main keys over songs originally written for a different key, the following convention over configuration approach is used instead.
- It will modulate from the current state's song key to the new key using the same enharmonic preference of the current state's key being modulated from. However, if the difference in number of accidentals for a given new key signature is greater by a certain tolerance value (currently hardcoded as
1
) in comparison to it's enharmonic key signature preference, it will switch to the enharmonic key signature instead to favor less accidentals. Thus, certain key signatures like Db and C# will not switch because difference in the number of accidentals between them is no greater than1
. - Also, if it modulates back to the prepared song's main key, it will always use the enharmonic preference of the song's main key instead.
Differences in enharmonic representations (number of flats - number of sharps)
C#/Db : -1*
D#/Eb: -7
F#/Gb: 0*
G#/Ab: -4
A#/Bb: -8
* Tolerated values within threshold of "1".
Beyond Gingkstep, for more advanced note/chord/scale manipulation, a library like https://github.com/jsrmath/sharp11 could come in useful.