romanText parsing of figures involving '4'

[malcolmsailor]

music21 version

7.2.0

Problem summary

The romanText parser understands figures including '4' in unexpected ways (other than perhaps 6/4 chords).

Steps to reproduce

for fig in ("64", "54", "5/4", "4", "754", "74"):
    score = music21.converter.parse(
        f"m1 C: V{fig}", format="romanText"
    ).flatten()
    rn = next(score.getElementsByClass(music21.roman.RomanNumeral))
    print(fig, rn.pitchClasses)

Expected vs. actual behavior

64 [2, 7, 11] # OK, although some would of course say V64 should be [7, 0, 4]
54 [2, 7, 9] # expected [7, 0, 2]
5/4 [2, 7, 9] # expected [7, 0, 2]
4 [2, 7] # expected [7, 0]
754 [0, 5, 7, 11] # expected [7, 0, 2, 5]
74 [9, 2, 7] # expected [7, 0, 5]

All the chords seem to be transposed up 7 semitones. (7 -> 2, 0 -> 7, etc.)

[jacobtylerwalls]

Thanks for the report. I think this is a consequence of some non-canonical figures e.g "54" or "4" nevertheless being run through the normal algorithm to determine the "bass" (as one would do for, say, iv6) instead of just ignoring the figures and using the scale degree of the roman numeral as the bass.

Workaround is to use [add4] notation to specify non-canonical figures (or [add4][omit3] etc):

>>> roman.RomanNumeral('V5[add4]', 'C').pitches
(<music21.pitch.Pitch G4>, <music21.pitch.Pitch B4>, <music21.pitch.Pitch C5>, <music21.pitch.Pitch D5>)

I'm sure Myke has thoughts. My inclination would be to only run the "solve for bass" algorithm when there is a canonical inversion (6, 63, 64, 653, 65, 643, 43, 642, 42). Seems more useful than updating the romanText parser to change "54" to "[add4]" notations.

[mscuthbert]

yeah, I think that Jacob's solution is best, but I would add to it "2" alone which is a shorthand for 642 by some older theorists. (Totally different from "9" alone. :-) ) and the inversions of 9th chords if spelled out directly, 6543, 6432, 7642. and possibly the 11th chord full spellings (no need for 13th chords since they saturate the diatonic).

The other probably exception is probably "5/4" and similar chords, where the slash sign could be used to indicate that something is definitely in inversion.

[MarkGotham]

Thanks @malcolmsailor , @jacobtylerwalls , @mscuthbert. I'm very glad to have stumbled across this just now. It would be wonderful to see this issue resolved well as it seems to be one of the main causes of friction for users of romanText.

First up, I'm sure we can we agree that in almost all cases, romanText is used for the kind of (tonal) music in which 54 is useful for expressing suspensions (i.e. a modification and not a stable chord in itself).

Currently:

• X[add4][omit3] is rather verbose (and fwiw not very satisfying as an expression of the suspension), so perhaps not a reasonable syntax for such a common entity;
• X54 is a seemingly logical work around, but is at best confusing as @malcolmsailor sets out;
• No better solution currently offered;
• The vast majority of prospective use cases are not just for suspensions in general, but for the double suspension cadence. Here:
  • there is even less even music theoretic agreement over how to handle 54 in this case (again as @malcolmsailor hints at above and cf. I64 vs V64 vs Cad64).
  • we perhaps need to split our solution to address both the general case and the logically exceptional (but actually most common in practice) specific case.

Specific case (easy fix for most uses in practice):

Given the above, and as we have a music21 solution to that special case in accepting Cad64, perhaps, we should we add Cad54 and/or Cad4 as a special string? (This can be implemented alongside whatever general solution we come up with for 54).

[MarkGotham]

General case (which warrants a separate comment, if not entire issue):

It might also be worth considering the closest match to this chord type within the current music21 provision: sus within harmony.ChordSymbol. How about including that or an equivalent within roman / romanText?

Admittedly, sus is not really from the Roman tradition, but would fit well here in that it's:

• perfectly clear, logical, and unambiguous;
• an expansion of the syntax (so doesn't actually change existing analyses some of which will have noticed this 54 issue and worked out the way to get the 'right' pitches);
• a much smaller step than creating some kind of secondary layer to emulate the more typical figured Roman notation in layers. E.g. (if you'll excuse the approximation):

  8-8-8-7
  6-5-5-5
  4-4-3-3
  V

  So maybe we add a [sus] category to complement [add] and [no]

• Support at least [sus4] standing in for [add4][omit3]
• Also [sus7] standing in for [add7][omit6]
• Not extending to the general case [sus{N}] standing in for [add{N}][omit{N-1}]
  • because [sus2] would typically stand in for [add2][omit3]
  • and others like [sus3] or [sus5] would be odd.
• Maybe raise an error if the relevant pitch is not in the chord?

[malcolmsailor]

there is even less even music theoretic agreement over how to handle 54 in this case

Is there indeed controversy about what the appropriate roman numeral to associate with 54 chords is? Suppose one needed to assign a roman numeral to (say) the pitches D-G-A followed by D-F#-A approaching a cadence in G major. I should have thought that "V" would be the unexceptionable choice (and figuring the suspension with a 54 would be optional depending on the granularity of the analysis). Yes, there is controversy in the case of 64 chords but that seems different since the "cadential 6/4 chord" contains the same pitch-classes as the I chord. If D-G-A in this context is a "I" chord, how does one explain the A, and why it is the G that needs to resolve and not the A?

Also, can you clarify, Mark, how the specific and general cases you are discussing are different? In either case, it seems to me that 54 (as well as all of the other chords I suggested) should have the specified intervals above the root implied by the roman numeral, and can be handled by a single rule.

E.g., suppose we are in C major. C major with a 4 suspension: I54 54 chord with G bass in the context of a cadence: V54

Can you clarify how you would expect these to be handled differently?