Crash when adding a Global time sig into a measure which is in Local time sig

I can't seem to reproduce.

Can you give more precise steps? For example, you mention notes without having entered them first.

Maybe you could do a screencast.

Yes, needs info for me too. I can not reproduce on this moment.

Your first image shows a corruption. Could you detail the first two steps?
Initially, you have a 4/4 time signature, right?
Then you fill some notes in the first measures, and you change the time signature for 3/4? Exact?

You say using the Ctlr key to drag and drop this time signature? What is the purpose, the interest to use this key for that?

Ctrl+drag is how oyu create a "local" time signature - one that affects only the given staff. Same for key signatures, btw.

Ok, I think I have never used this feature yet. I'm surprised myself! Glad to know.

Confirmed, but only with the template file (Guitar + Tablature)
I cannot reproduce via Blank -> "I" -> choice of instruments etc.

Agree with that?

Managed to reproduce with blank file.

Using MuseScore 2.0 Nightly Build 0d05735 - Mac 10.7.5.

Ok, this issue appeared on November 25

This nigthly is correct : https://github.com/musescore/MuseScore/commit/0a59df0a1f6cc004411ed943e…

This one not: https://github.com/musescore/MuseScore/commit/f6d1a2950fc1b636e481fbd7e…

So, the previous commit is probably incriminated? https://github.com/musescore/MuseScore/commit/eacac5cedc5a575ac839709e4…

Not specific to standard staff and tab staff, so: adaptation for the title.

Example:

1. "My first score"
2. Add a linked staff (or not linked, same result with simply add staff)
3. Fill the first measure (in 4/4) with some notes
4. Drag an drop an local time signature (with Ctrl) on the second measure

5. Fill the second and third measures with notes
6. Drag and drop a new time signature (so, without Ctrl), 6/4 e.g. in the third measure

Result: crash

Here a test file: test file.mscz

EDIT I confirm that the issue occured on November 25 (for the crash). See details in previous comment # 13.
But, I see corruption in similar cases in very former Nigthlies. So, continue to investigate.

I reworded the title because it is fundamentally the nature of this issue. Two staves, linked or not, are not necessary for understanding.

The main point of this issue is the mixed use of local and global time signatures, major corruption source.

In this example below : a first measure in 4/4 (global time sig), followed by a local time sig change (drag-drop 3/4 with Ctrl) for both measures following.

The issue appears by entering a new global time sig (2/4) into a measure that was under a local time sig. Result: hanging, then crash.

It works (in the sense: no crash immediatly) if you apply a new global time sig (2/4) after, so, into measure 4.

It works? Not really! Indeed you avoid the first crash - as I mentioned in comment #13 with the Nightly on November 25: f6d1a29
But if you continue these operations, corruption appears, which leads in a second time to crash by copy-paste, repeated measures, by selecting one of them, etc.

- Adding of some files for testing: test global local 2.mscz and other test.mscz

I wonder if the behavior has changed with the recent fix for #47496: Time signature missing after undo of local time signature? I'm not at my computer to check.

I had seen and verified immediately. I just checked again on last Nightly ff962d5
This issue is not fixed.

The implementation of local time signature is not complete in that some "special cases" are not handled. If a staff with local time signature contains notes and the time signature is changed its unclear what to do with this notes. I believe there is nothing sensible we can do with them. So the simplest solution is to disallow any operations on non empty measures with local time signature.
Empty measures can be handled as its easy to reinterpret a full measure rest.

That's fine by me. I'm less interested in whether an operation like this "works". I just don't see want to see crashes or corruptions if we can help it.

Obvious? That's not what I'd expect at all. The whole point of local time signatures is to *stretch* (increase or decrease) the time relative to other staves. So a 4/4 measure with four quarters - whetehr notes or rests is completely irrelevant - I'd expect to be stretched into a quadruplet in 3/4 time. And in any event, the issue at hand is more about happens not when *creating* a local time signature, but when *uncreating* it. So it you already have three (stretched) quarters in 3/4 time, I'd expect them to be turned into half note triplets in 4/4, but what if changing to 5/4? And what if there were triplets in the 3/4?

Rather than trying to special case certian things were we think we can second-guess the intended effect, I'd much rather we go with a simple disabling of this change for non-empty measures. Or, perhaps, simply have the measures contents automatically deleted. The point is to have reliable behavior for what is surely an *extremely* rare and special case operation, not to try to guess what someone is maybe going to want in these extremely rare cases and spending a lot of programming effort trying to automate soemthing that quite likely to be a wrong guess anyhow.

a partial fix is now in 7a1d5c2

The partial fix, as I understand it, basically disallows adding a local time signature to an non-empty measure. It does not, however, disallow *removing* one (either by deletion, or by replacing it with a regular time signature). So those cases still cause corruption. We do sometimes get an error on deletion of the local time sig that we "Cannot rewrite measures: Tuplet would cross measure" (even though no literal tuplets are involved), but then the time sig is deleted anyhow and the score is corrupt.

There is also still corruption even if we add add a "real" time signature to an empty measure that currenltly has a local time signature applied.

1) score for two instruments, 4/4
2) ctrl+drag 6/8 to bottom staff measure 2
3) drag 4/4 to measure 3
4) add notes to measure 3, bottom staff

Result: bottom staff shows 4/4 but still acts like 6/8

If I can, I plan to do the following:

1) disable removal of local time signature if there are non-empty measures
2) fix time signature map when adding global time signature to a measure that currently has a local time signature applied

Combined with the changed I made recently to disable accidental creation of local time signatures via the time signature dialog, my hope is to limit the scope of local time signatures to situations where they actually work (and they *do* work well within that scope, I have found).

I don't expect to get to this within the next few hours. I'll assign myself if/when I start to look at it.

I'm finding other issues with local time signatures also.

- If you try to add a local time signature and there are non-empty measures, you get a message telling you it won't work. However, an empty time signature segment is created. If you later try to add a time signature change before that point - local or global, doesn't matter - it will only take effect up to the point of the empty time signature segment. Measures after that will be left alone, and are now corrupt, since you have actually changed the time signature. Of course, adding a local time signature should not have worked any more than it did the first time you tried; that's how I discovered this bug. I was not understanding why sometimes I get the message and other times I didn't.

Probably won't be able to deal with all of this, but will see what I can do.

At this point, my PR https://github.com/musescore/MuseScore/pull/1898 addresses a good chunk of this with what should be no impact on anything else (except to the extent it fixes some similar problems involving tuplets). So that's good.

The main thing left is something we can probably deal with as well, but it's code that will be hit on all time sigature changes, so it will be important to get it right. Here are the specific steps to reproduce the problem:

1) new score, 4/4
2) ctrl+drag 6/8 to measure 2
3) drag 4/4 to measure 3

Result: score is corrupt from measure 3 on - the measures display as 4/4, but they were never rewritten, so the measure rests as all still set to 6/8, and attempting to enter notes will only allow three beats (equivalent of 6/8).

It actually works fine if you use any time signature but 4/4 at step 3. The problem is here:

https://github.com/musescore/MuseScore/blob/b4b5e2806381551db7aafc4d2c7…

We are trying to decide if we need to rewrite the measures. What happens is that the sigmap is returning the global time signature, not the local, so we think we're still in 4/4 (and of course, if there were other staves, they *would* be in 4/4). We need to check to see if there is a local time signature in effect and go ahead and rewrite if so. At this point in the code, we have that information available for the staff we actually dragged the time signature too. But we really need to see if *any* staff has a local time signature. Ideally, we'd write only the staves that need it. Need to think about that more, and it's late now, so it will have to wait. But I can at least verify that adding "&& stretch == 1" the the line above fixes the issue at hand with the steps shown above. Just a matter of time to refine it further.

At that point, I think I'll be happy with the state of local time signatures.

Fixed in 71eef93f69

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