Automatic keyboard inversions break with {transpose}

[gwyndaf]

Testing keyboard inversions with _031. Seems to work nicely without transposition, but:

{transpose: +2}
Let's play a [C], then invert to [C/G], then again to [C/E]

gives

As far as I can tell, it's introducing rogue notes B and G# in the two inversions. These are 2 semitones up from the bass note of the post-transpose inversion. Maybe transposition is being applied again to the bass, and (maybe related) the corresponding tone (A or F#) isn't being 'removed' from the top of the chord.

[sciurius]

Good catch. _32 should fix this.

[gwyndaf]

_032 works nicely for the test sample. But, apologies, my {transpose} diagnosis might have been premature.

With a bigger sample of chords, and no {transpose}, I get

Both Cm inversions look fine, as do F/A and G/B, but F/C and G/D duplicate the bass note.

Both Bm inversions duplicate the bass note, but Bm/D is odd because the inversion itself looks wrong - I think the F# should be an octave lower.

I can't figure out any clear pattern in the extra notes, except:

1. It's only with the inversions
2. It's always the /bass note that gets duplicated

[sciurius]

Can you try _033?

[gwyndaf]

_033 works nicely for that (larger) test sample.

I'll do further testing with some 7, maj7, dim chords etc. (assuming this functionality should work for all chord types).

[gwyndaf]

That seems more robust, both with a few real-life examples and more extensive test sample.

One observation: [Cdim7/Bbb] is rejected as 'unknown chord'. TBH it's not something I've ever needed myself, but perhaps that's a case that might arise, especially with dim7 chords?

[sciurius]

ChordPro does not understand double-flat (and double-sharp, and microtones). And I have no plans to support this.