'var' tag in romanText

[malcolmsailor]

music21 version

7.2.1

Problem summary

If a number is not appended to a variant reading (e.g., if we have m1var rather than m1var1), the romanText parser seems to interpret "var" as a roman numeral.

Tymoczko et al. 2019 only gives examples of var1 and not of var, but the text seems to imply that var should be ok:

In any case there is at least one piece (Book 4, 16) in the Monteverdi madrigal corpus (supervised I believe by Tymockzo) that uses var.

Steps to reproduce

>>> import music21
>>> rntxt1 = """m1 I
... m1var1 iii
... m2 V
... """
>>> score = music21.converter.parse(rntxt1, format="romanText").flatten()
>>> for rn in score.getElementsByClass(music21.roman.RomanNumeral):
...     print(rn)
... 
<music21.roman.RomanNumeral I in C major>
<music21.roman.RomanNumeral V in C major>
>>> rntxt2 = """m1 I
... m1var iii
... m2 V
... """
>>> score = music21.converter.parse(rntxt2, format="romanText").flatten()
for rn in score.getElementsByClass(music21.roman.RomanNumeral):
    print(rn)>>> for rn in score.getElementsByClass(music21.roman.RomanNumeral):
...     print(rn)
... 
<music21.roman.RomanNumeral I in C major>
<music21.roman.RomanNumeral var in C major>
<music21.roman.RomanNumeral V in C major>

[MarkGotham]

Thanks for this @malcolmsailor .

Firstly, DT's updated analyses fix the specific, immediate issue: see https://github.com/MarkGotham/When-in-Rome/commit/e59b5d5b6aa80b3a74786a0c201c391ab9769373 There's no longer any cases of var (with trailing space) in the Monteverdi or anywhere in the (meta-)corpus.

I'm inclined to say we stick with the number as required syntax.

That still leaves the question of how to handle the syntax error if and when it does come up.

1. (Currently) treating it as a RomanNumeral: clearly not ideal.
2. Automatic mapping (of var to var1 in this case): I'd support that, though I think @mscuthbert (understandably) doesn't want to offer any support for syntax errors.
3. Ignore the line entirely: better than creating errant RomanNumeral objects that will be picked up for other processing.
4. Print a warning: should prob. do this in any case, right?

Option 2, this raises a wider point. FWIW, I'm happy to use When-in-Rome to offer a more flexible pre-parser script that does the best it can with errors of this kind. That would be offer some friendly flexibility without altering the strict version of record here on m21. I have my eye on anything that is both easy to get slightly wrong and for which it's easy to offer a clear, unambiguous correction. Here are a few options (mapped out here in case we do want any of this on music21 after all). I'd need to check them all, but as I recall:

• beat given but no chord (i.e. two beats specified with no chord: b[0-9]+ b[0-9]) = ignore unused beat entry
• measure given, but nothing further (m[0-9]+ $) = ignore (blank line is better).
• use of .3 = map to .33 (.3 is legitimate encoding of a 5tuplet, but obviously .33 is almost always what's actually intended ... this one is a bit of a hack workaround)
• plausible but wrong variants on the measure equality syntax (should be mX-Y = mA-B) = accept slight variants like mX-mY = mA-mB

Some of these stop the whole analysis from parsing; others parse, but with errors (e.g. with off-by-one measure errors).