2.9.0 chord search issues

[HertzDevil]

• The documentation claims to support arbitrary slash chords, but this really only works for inverted chords and the slash chords already supported by Hookpad (e.g. C/B but not C/B♭). This in turn causes the full spellings of those slash chords to be unsupported (e.g. Cmaj7/B doesn’t produce C/B).
• Applied V¹¹/ chords produce incorrect slash chords, even without borrowing from a different key, e.g. V¹¹/IV is B/C instead of B♭/C. It follows that chord search also uses these incorrect chords.
• Power chords (e.g. C5), omitted chords (e.g. Cno3), and thirteenth chords (e.g. Fmaj13) aren’t supported.
• Some ninth and eleventh chords cannot be searched, e.g. Bb9, probably because of ambiguity between B♭9 and B(add♭9).
• Altered chord support is very poor, and seems to cover only ♭5, ♯5, plus extensions that already appear on unaltered chords (m11b9, maj9#11). Chords with multiple extensions are unsupported.
• Certain minor chords produce ♯5 on a diminished chord but not any borrowed chords, e.g. Bm produces vii^o(♯5) rather than vii_(lyd).
• Supermodal chords of the harmonic scale are unsupported, most notably F#dim7. (F#dim6 works by producing m6(♭5), however this isn’t a normal spelling.)
• Roman numerals in chord search follow popular music rules while the actual displayed chords follow common practice rules, so things like VII in a minor key produce ♯VII. (This Hookpad 1 setting is still unavailable on 2, by the way.)
• The order of applied Roman numerals is switched (e.g. IV7/V produces V⁷/IV and vice versa).
• viio produces I instead of vii^o.
• i7dor does not actually borrow from Dorian as the documentation states.

[Ryan]

Thanks for the detailed report, as always!

To clarify a couple points:

• Chord search is a reverse lookup, and so can only support chords that can be built using options in the chord interface (plus a limited range of borrowed supermodes). This means arbitrary slash chords are not supported, since some slash chords cannot be created functionally using Hookpad’s current interface.
• We’ve further restricted this set of available chords as a compromise for speed, library size, and usability. This is the reason why altered chords have relatively poor support for the moment, but we are working on improving this. From a usability perspective, (most) chords with a #9 can be found by searching the base chord and then adding the #9 from the chord UI. Power chords are probably missing for this same reason, although this was an oversight.
• Since a given chord can have multiple relative spellings (e.g. I = I(mix) = V/IV), we attempt to sort the results to show the most common spellings first. This however, is a work in progress

[HertzDevil]

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

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 V¹¹/.
  • 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 vi₅⁶_sus4, but this chord is in fact Am7sus4/D, and the correct one should be ii_sus4^(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 ii^o(♭5)_(maj) over the diatonic ii^o, 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.

[Ryan]

Very impressive detective work. Happy to share the details of how this is implemented. As I mentioned, this is a work in progress, and there are still a lot of bugs to be worked out.

Here are baseline values the create the chord combinations:

As you can see, we are currently limiting explicit alterations to only the 5th-alterations. Any other alterations spelled on chords are implicit to the scale, for example in C Major, iii9 would be Em7(b9). We found that explicitly adding all combinations of alterations created a lot of nonsense chords and made the lookup prohibitively large. I’m sure we could pare this down smartly, but haven’t had the time to look into that yet.

Regarding the parsing, I’m confident we have a lot of bugs to work out (the bug reports are very useful). Both Roman numerals and absolute chords names are looked up directly. Arabic numeral chords are converted to Roman numerals based on the current key and then are also looked up directly. Errors in finding chords in the lookup can be attributed to parsing errors, parsing oversights (we are not looking for ø for example yet), improper conditioning of the chords to match the lookup key, or a combination of the above.