2.9.0 chord search issues

bug reports
4

I managed to parse the chord search database myself, and found that the altered chords are in fact there:

image
image.png1331×1036 14.1 KB

If the chord search tool is a mere reverse lookup, I should expect these chords to show up if I simply type them into the search field, but most of them don’t. Upon further inspection I believe this is what Hookpad does right now:

  • Roman numerals are looked up in the database if they contain only the scale degree, chord type (including +/ø/o and the topmost accidental), and inversion; everything else like add or V/ is parsed and applied to the search results afterwards.
  • Arabic numerals are fully parsed, the database doesn’t have them.
  • Chord symbols are only partially parsed to determine their root pitches; Hookpad tranposes the current key to its relative major, then C Major (applying an identical transposition to the search query), and then performs database lookup with the transposed query.

Thus most bugs can be categorized into one of the following:

  • Errors while parsing the search query
    • Applied degree and target degree are swapped in secondary chords.
    • Parentheses are ignored, even mismatched ones.
    • Roman / Arabic numerals seem to parse suspensions with /sus(#|b)?(2|4)*/ rather than /sus(2|4)?/. Roman numerals don’t need the accidentals, as the actual qualities of the suspensions depend on the current scale. As a special case, susb and sus# produce susNaN chords that cannot be selected.
    • Extension parsing for Roman numerals is very lax; it could apparently accept /(#|b|B|1|3|5|9)*/, but then silently reject invalid extensions.
    • Accidentals for chord symbols accept /(#|b|x|B)+/ (is uppercase B for double flat?) but all subsequent accidentals are considered equal to the first one. Mixed accidentals shouldn’t be allowed.
    • The database contains Roman numerals for half diminished chords using ø, but none of them can be searched for some reason.
  • Mismatches resulting from incorrect Roman numeral / chord symbol generation
    • Slash chords for applied V11/.
    • Using add13 and ♯5 on a major triad produces an erroneous 6 chord. This doesn’t affect diatonic chords but can be seen for example with E6 producing V+(add6)(♯5)/vi.
    • All chord options apply directly to 6 and m6 chords resulting from first inversions of seventh chords; this is only correct for ♭5 and ♯5 (as these end up modifying the third’s quality), all others are wrong. For example D6sus4 produces vi56sus4, but this chord is in fact Am7sus4/D, and the correct one should be iisus4(add6). (Third inversions of seventh chords with added 13ths are correct.)
  • Improper priority mapping from pitch sets to chords
    • Preferring dim(♯5) over m for most borrowed minor chords.
    • Minor keys prefer iio(♭5)(maj) over the diatonic iio, e.g. Bo in A Minor. Same goes for all non-major keys.

Is there a technical reason the chord symbols cannot be fully parsed? Doing so would greatly reduce the combinatorial explosion in the chord database, making room for those alternate chord spellings unavailable in Hookpad. I can’t imagine full chord parsing would put a significant burden on the search tool’s performance.