Custom time signatures lose denominator
Reported version
3.5
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
duplicate
Regression
Yes
Workaround
Yes
Project
This is something reported on forums a couple of times but I don't see an issue for it. It's easy to reproduce:
1) using 3.4.2 or earlier, create a score with a 7/4 time signature using default settings, or load the attached
2) look at the time signature
Result: only the "7" appears. That's because of a bug that was (mostly) fixed #281071: Can't have single number when adding custom time signature, but it has an impact on existing scores that were unwittingly relying on the bug. I'm still not 100% if all existing scores will trigger this or not, but this one has numerator text set but not denominator, and that seems the trigger.
Comments
See #308139: Time signatures created pre-3.5 need special handling to avoid unintended loss of denominator
Thanks! I searched for “time signature” and “timesig”, should have tried “meter” too!
Me too at first ;-)
This was probably caused by the fix for “Other” timesignatures.
I’d suggest that, when scores prepared by an older 3.x version are loaded, whose TimeSig lacks sigD but also does not have textN (or at least not textN equal to U+E911 or one of the other SymId::mensuralProlation* ones), that the appropriate migration should be done on loading, since 3.x never had working Others (or just numerators) before, in contrast to 2.x scores.