#1633 Chord name ruler shows nothing when notation or matrix editor opens

[Yves Guillemot]

• Open a file containing chords (i.e. the attached file)
• With notation or matrix editor, open a segment containing chords
• If needed, show the chord name ruler
  The chord name ruler is empty
• Modify anything on the edited segment
  The chords are now displayed on the ruler

[Mark R. Rubin]

Thanks for pointing this out. I've been meaning to figure out why the ruler shows up sometimes and not at others but have been too busy with other self-assigned tasks.

The other obvious bug is that the chords always show "0" for the octave. I did take the time to look into that, and the code is both clearly wrong and easily fixable. But again it went onto my personal "to do" list.

And if I do get around to it, I'm likely to add a whole bunch of "Feature Request-y" stuff, like more chords (sus2 and sus4, 9ths, 11ths, 13ths, add9, ,#9), enharmonic chords (C6 vs Am7 not to mention Csus4 vs Fsus2) (unless the key analysis A.I. I saw in the code is smart enough to know which one is "right" in a given situation), some indication of the inversion/voicing (maybe "1st", "2nd", or alternately slash chords with the bass note listed), a checkbox to consider notes only in the current segment/track/instrument vs everything playing at that time, another checkbox to include notes in some time range to detect arpeggiated chords, and one to annotate notes as to their function in the chord (e.g. "r", "b3", "5", "b7" for a m7) including inversions, voicings, and repeated chord tones. And several other ideas. ;)

So maybe it would be better if someone else got to this one before I do. ;) ;) ;)

[Yves Guillemot]

Should be fixed in branch Fix1633.
This fix also removes the always 0 octave number Mark pointed out and adds in notation and matrix the chord name ruler tooltip found in track editor.

[Mark R. Rubin]

Thanks, Yves. This really helps.

At first I was surprised to find you had completely removed the octave number instead of fixing it to be correct. But I thought about it, and can see the logic. A user can always look at the notes (while working in either the Notation or Matrix Editor) to see the octave, so except for a very MIDI-oriented mindset, it's redundant.

I still think AnalysisTypes.cpp could use some more work in the future. If nothing else, there's things like:

    // This is an ugly loop. Is there a better way to iterate backwards
    // through an STL container?

Uhh ... yes, there is. A lot has changed in C++ since Guillaume Laurent wrote that comment in 2006. ;) But it's just a minor, unimportant nit-pick -- I'm sure the method containing the code isn't performance-critical.

I'd still like to try to implement some of the craziness I mentioned above. I'm too busy hacking other stuff into RG right now to work on it. I'd love to see automatic export of the chord names to Lilypond. Imagine playing a jazz piece on piano and not exporting the left-hand bass clef staff with the chords, instead leaving only the treble clef melody line and the chord names for a perfect jazz "lead sheet". Maybe someday. ;)

But here's one trivial thing I'd like to suggest, for your and the rest of the maintainers' consideration. Again in AnalysisTypes.cpp, in ChordLabel::ChordLabel(Key key, int mask, int /* bass */), disable one line:

#if 0   // t4osDEBUG
    if (Pitch(i->second.m_rootPitch).isDiatonicInKey(key))
#endif
    {
        m_data = i->second;
    }

I haven't tested it fully, but it seems to do what I intended, which is report all chords, not just the ones that are in the current key. My sophisticated jazz-playing friends rightly accuse me of only liking simple pop/rock songs, but even those often have out-of-key chords. I realize this would be a change, and (sigh) maybe needs a setting to enable and disable, but the chord name ruler was already so broken before your fix that that I can't imagine anyone complaining.

Just a suggestion. Thanks again for fixing the chord ruler annoyances.

[Yves Guillemot]

At first I was surprised to find you had completely removed the octave number instead of fixing it to be correct.

To say the truth I didn't succeed et first attempt to get the right octave number.
Then I thought that displaying the octave number of the chord root note is perhaps not the better thing to do.
See attachment: the two chords have the same root note (and the same octave number) but nevertheless don't seem to have the same hight.

That said, I'm by no means an expert about chords and I doubt I'll find time to work on such features in the next months.

[Mark R. Rubin]

That's a good example of why the octave number is semi-meaningless.

The ones I was thinking about were canonical guitar chords, which often have repeated root notes such as root-fifth-root-third-fifth-root or root-third-fifth-root-third-root ("E" and "G" open chords respectively, or the same voicings transposed to different roots in the "CAGED" system of barre chords). And it's not just guitar -- multiple roots are common in two-handed piano playing and ensemble/orchestra scores. Which one of the multiple roots' octaves would be the "correct" one? They're not even inversions in the traditional sense of the term, so that doesn't help disambiguate them. I guess one could say "use the lowest root's octave" ... or the highest, or the middle. Any choice is just arbitrary.

One way or another, I think removing the octave numbers is the right thing to do. Unless some user, somewhere, is going to freak out the always-"0" numbers are gone and demand we put in a switch to restore the old behavior. ;)

[Ted Felix]

Merged as [132624]. Please test latest git.