Esoteric issue: Indicating within-measure positions using metrical beats when the meter changes

[johentsch]

https://github.com/MarkGotham/When-in-Rome/blob/6c923a1a21b1e33a8b684e718c3ee15a73296eb0/Corpus/Piano_Sonatas/Mozart%2C_Wolfgang_Amadeus/K284/3/analysis.txt#L228

m. 221 is divided into the last half bar in 2/2 meter of variation XI and the first quarter-length upbeat measure of variation XII in 3/4 meter. Indicitating the position of V6 as b. 2 is therefore correct if we consider m. 221 to be in 2/2 and wrong if we consider it to be in 3/4. In the encoding here, the measure is still in 2/2 so maybe everything is in order...

[johentsch]

Am I looking for trouble? Definitely.

[MarkGotham]

Hello! Delightful to have you and your trouble-bringing around! Welcome, welcome, welcome.

This is certainly a known limitation of Roman text ... and of most off-score analysis formats ... including the DCML ;-).

In short, there's no mechanism for encoding either of the solutions used elsewhere for this:

• mid-measure time signature changes (this is also not commonly supported by other, actual score-rendering formats)
• split measure (i.e., a difference between the nominal an actual length of a measure – we can only do that with anacruses).

The place to report Romantext issues would be music21, but I rather doubt that Myke would accept this functionality even if you somehow work out a sensible solution to this.

I also think it falls under the known edge cases we'd consider beyond the scope of Romantext and would expect to try and take on through the separate measure alignment routines. In this case, that routine would be:

• recognise the issue by comparing this with a more detailed encoding of the score itself
• split the 2/2 measure into two parts, at the point that makes the first measure the correct length (nominal 2/2, actual 1/2);
• apply the new time signature to the second new measure (3/4)
• make that new, second measure the correct length (nominal 3/4, actual 1/4)
• remove (or hide) the time signature from the following measure as it's now a duplicate

I honestly don't know whether the existing code can deal with that ... let's go and find out! I do think it's realistic to achieve this fix (with the generalised logic solving for this specific case), but can imagine problems identifying it if there are many other issues around confounding the diagnosis.

Thanks very much for pointing out this deliciously involved test case ... see you on the other repo!

[MarkGotham]

I stand corrected ... @mscuthbert has independently expressed an interest in this topic ;)

Re-opening; and removing won't fix

(Still a good topic for bar-measure)