Time signatures created pre-3.5 need special handling to avoid unintended loss of denominator

(sample) score needed

Confirmened, but check the time signature properties, even in 3.4.2 the denominator is empty. So I'd rather call it a bug in 3.4.2 that got fixed in 3.5?

Well, the empty denominator is there in 3.4.2 too, and those score clearly have been last saved with that too

I have gotten this updating to 3.5 with my very large time signatures palette. 1/4, 32/4, 40/4, 7/4, and 8/4 were some of the ones affected. For some reason, all of the time signatures affected were with a denominator of 4. I first noticed this when I updated a score with some 1/4, and the 4 disappeared from the palette and two staves. It can be fixed in the score but not the palette for some reason.

You'll need to delete the one in the palette including the master palette, create a new one and put in your palette (at least in theory).

Apparently caused by the fix for #282246: "Other" appearance in Time Signature Properties does not work

I'll take a look at this.

Related to #281071: Can't have single number when adding custom time signature

Oops, I only wanted the type to be "Functional".

See also @Marc's remarks at https://github.com/musescore/MuseScore/pull/5315#discussion_r478510695

See #281071: Can't have single number when adding custom time signature.

Wrong.

No, it is the exact opposite

I looked into this a bit, and I don't think that it's the layout of the time signatures that needs fixing. It is the "Create Time Signatures" dialogue that is causing this problem, it adds a special text to the corresponding position whenever the numerator or denominator is changed in that dialogue (when creating custom time signatures). It has been the case for quite some time, but before 3.5 this action wasn't a problem, because even if the denominator text was empty and the numerator text was not, the denominator still got shown on the score using the default "4". This was in fact a bug reported at #281071: Can't have single number when adding custom time signature. Now that this bug has been fixed, if the denominator text is empty but the numerator text is not, only the numerator is shown.

Which means, sadly, that you have to change all the problematic time signatures in your scores yourself (delete the existing special text for the numerator, so that both special text fields are blank, so that the default figures are shown), because the values stored in these are wrong themselves, not the layout done by MuseScore. :-(

Blame #281071: Can't have single number when adding custom time signature for this, it's it which hid this problem so that you didn't notice :-)

See https://github.com/musescore/MuseScore/pull/6507.

I agree the proposed change to the dialog is good, but it doesn’t address the issue reported here - it addresses a different issue not yet reported (but should be).

I do think we should include some sort of compatibility fix on read of older scores to address this issue.

A PR was already created based on the old issue. Please open another thread for this suggestion (or don't if you can address this issue yourself!).

Well, no, you changed the scope of this issue into something related but different

You mean me? Yeah I admit I did that too, but that was before any PR was created. Now if we change the issue title any more, the link between the existing PR and the issue is broken (screwed up) and that confuses stuff, right?

Or it should be me who create another issue. Does this sound more reasonable?

Well, you definitely should create a new issue for the dialog - and I agree it's an issue worth fixing, if much less serious - and amend your PR commit message to reference that one.

Meanwhile, I think this issue is a serious regression, since scores that previously worked and were created perfectly correctly stop working correctly now. I think the fix is probably to check version number on read of a time signature, and fix this case there, either adding the missing denominator text, or maybe removing the numerator text if it matches the actual numerator, so it's consistent with what new scores will look like with your other fix (empty strings by default).

As for who makes that change, I don't really care. I can do if it no one else agrees this a serious enough regression to warrant spending their time on a fix, but I'd rather see someone who actually worked on this code do it.

Yes. Create a new issue, change the PR title, git commit --amend the commit title, git push -f

oops

But there's also the problem of mistreating other time signatures which are meant to only have numerators. How can you tell the difference between those and the ones we're talking about here?

Meanwhile, actually later, I'll create another issue for my fix. (EDIT: done, see #309754: Create Time Signature dialogue doesn't need to add special text whenever the internal value of nominator or denominator is changed)

Pre-3.5 there were no time signatures with only numerators. If a time signature had only numerator text, you still got a denominator. 3.5 needs to continue to honor that, because the vast majority of such scores, the missing denominator was an accident. For the very small percentage of scores where someone actually meant to have only s numerator, they weren't getting it anyhow, so there is no compatibility. If they want to take advantage of the new feature allowing numerator only, they can go to time signature properties and set it up. It's reasonable to ask someone to take that extra step on their existing scores to get different behavior than they got before, especially if that different behavior is something most people would not want.

So to be clear: I am only talking about altering the behavior of pre-3.5 scores, by fixing them on on read to display they always did in the past. Newly added time signatures would not be affected one bit by my suggested change.

OK, but then the compatibility fix should only be adding a denominator text, not deleting the numerator text, because if we did the latter it could change to something totally different, if the internal numerator is not the same as the numerator text. But then there's the downside of having redundant information stored in most cases (where the internal value is the same as written value) though.

That's why I said "maybe removing the numerator text if it matches the actual numerator" :-). As in, upon reading a timesig - presumably after the read is complete, like at the very end of TimeSig::read():

if this is a pre-3.5 score and denominator text is empty and numerator text matches actual numerator
then delete numerator text

I agree I'd rather not see the unnecessary extra info written. But I'd live with it if something I'm not foreseeing goes wrong with the approach I just outlined above. It would only be for pre-3.5 scores with custom time signatures that are then re-saved in 3.5. And it's harmless as far as I can tell.

BTW, in my brief testing, this isn't an issue for 2.x scores, probably because the weird dialog quirk that you fixed in your other PR didn't exist there.

Oops, missed it :-)

So yeah, I'll try to fix this issue tomorrow :-)

See https://github.com/musescore/MuseScore/pull/6513.

Fixed in branch 3.x, commit f9b7a41f58

_fix #308139: time signatures created pre-3.5 need special handling to avoid unintended loss of denominator

If the numerator text is not empty but the denominator text is, we need special handling because this kind of time signatures look different in 3.4.x and 3.5.x. The denominator is missing in 3.5.x, and this change is not good and expected.

In this situation, if the numerator text is the same as the internal numerator value, the numerator text is removed, changing the appearance of the time signature back to the default look, showing both the numerator and the denominator. If the numerator text is not the same as the internal numerator value, a denominator text is complemented so that both figures are shown without them being different than in 3.4.x.

See https://musescore.org/en/node/308139#comment-1022363._

Fixed in branch 3.x, commit 591178fe71

_Merge pull request #6513 from Howard-C/timesig_compatibility_fix

fix #308139: time signatures created pre-3.5 need special handling to avoid unintended loss of denominator_

Automatically closed -- issue fixed for 2 weeks with no activity.