Ok, I edited my first report (and title)
It concerns the case if all the score (containing 100 or 32 or 4 measures etc.) is selected, and the measures joined - I have checked first with a test file of 2 measures :)
(then all, with "Untitled" score)
And so, same crash with 2.0
"This operation is rarely useful "
Maybe/probably. But if it works by joining eg 31 measures in a score of 32 measures, why would not it work by joining the 32 measures?
This is the peculiarity of this issue (and so, always critical in my opinion)
The crash occurs any time there is only a single measure in the score and its actual duration doesn't match the nominal and then we try to change the time signature. Doesn't matter if we arrive in that situation by joining measure or using Measure Properties. The crash occurs in cmdAddTimeSig(). We detect we have a measure where nominal duration is not the same as actual and it's the first measure of the piece, so we think maybe it's a pickup measure and try to handle it specially. What we do is leave the pickup measure alone and then start and rewriting measure starting with the next measure. But of course there is no next measure, and we don't check for this, hence the crash.
Easy fix is to skip the operation entirely in this case. But it's debatable whether the way we handle the pickup case is really what people would want. If I have a piece in 4/4 with a one beat pickup, and then I change the first measure to 3/4, the current behavior is to keep the one beat pickup and then start rewriting measures after that. So if there are any other random measures with actual duration different than nominal, they get rewritten (changed to 3/4 (both actual and nominal), but the pickup measure keeps its 1/4 actual. I guess I can see why this might make sense, but I'm not super convinced.
My question now is: how did this situation come up? Was there a real world scenario in which it made sense to have a large single measure with actual duration not the same as nominal, and then to change its time signature? Was the intention to change the time signature to match the actual duration? Or was it to split the measure according to the new time signature? Or something else?
The intention? Nothing of particular.
Very simply, and as it happens sometimes, you are checking / testing something, and you fall, on the way, on something else! :)
So, if the crash can be fixed "easily" and safely (ie without any unwanted side effect), it's always better. Otherwise, the probable rarity (?) of this crash does not merit than more than being simply known and referenced.
As you want, but it's remain a crash ( = critical by nature) received in a minimal sequence of steps (select all, join measures, change time signature), not more.
Comments
But not in 2.0.x, so a regression?
In reply to But not in 2.0.x, so a… by Jojo-Schmitz
Ok, I edited my first report (and title)
It concerns the case if all the score (containing 100 or 32 or 4 measures etc.) is selected, and the measures joined - I have checked first with a test file of 2 measures :)
(then all, with "Untitled" score)
And so, same crash with 2.0
This operation is rarely useful or is it? So I'd degrade severity to major.
I guess the cause to be some off by one error.
In reply to This operation is rarely… by Jojo-Schmitz
"This operation is rarely useful "
Maybe/probably. But if it works by joining eg 31 measures in a score of 32 measures, why would not it work by joining the 32 measures?
This is the peculiarity of this issue (and so, always critical in my opinion)
The crash occurs any time there is only a single measure in the score and its actual duration doesn't match the nominal and then we try to change the time signature. Doesn't matter if we arrive in that situation by joining measure or using Measure Properties. The crash occurs in cmdAddTimeSig(). We detect we have a measure where nominal duration is not the same as actual and it's the first measure of the piece, so we think maybe it's a pickup measure and try to handle it specially. What we do is leave the pickup measure alone and then start and rewriting measure starting with the next measure. But of course there is no next measure, and we don't check for this, hence the crash.
Easy fix is to skip the operation entirely in this case. But it's debatable whether the way we handle the pickup case is really what people would want. If I have a piece in 4/4 with a one beat pickup, and then I change the first measure to 3/4, the current behavior is to keep the one beat pickup and then start rewriting measures after that. So if there are any other random measures with actual duration different than nominal, they get rewritten (changed to 3/4 (both actual and nominal), but the pickup measure keeps its 1/4 actual. I guess I can see why this might make sense, but I'm not super convinced.
My question now is: how did this situation come up? Was there a real world scenario in which it made sense to have a large single measure with actual duration not the same as nominal, and then to change its time signature? Was the intention to change the time signature to match the actual duration? Or was it to split the measure according to the new time signature? Or something else?
The intention? Nothing of particular.
Very simply, and as it happens sometimes, you are checking / testing something, and you fall, on the way, on something else! :)
So, if the crash can be fixed "easily" and safely (ie without any unwanted side effect), it's always better. Otherwise, the probable rarity (?) of this crash does not merit than more than being simply known and referenced.
And this is why I suggested to downgrade to major. Doing it now ;-)
In reply to And this is why I suggested… by Jojo-Schmitz
As you want, but it's remain a crash ( = critical by nature) received in a minimal sequence of steps (select all, join measures, change time signature), not more.
Yes, but in a corner case that is pretty unlikely to happen in real life
I can see it coming up, even if it hasn't really yet :-). Anyhow, this fixes it:
https://github.com/musescore/MuseScore/pull/3304
Fixed in branch master, commit 98f490cd60
fix #255646: crash changing actual duration of only measure
Fixed in branch master, commit 7da19a0082
Merge pull request #3304 from MarcSabatella/255646-actual-timesig-crash
fix #255646: crash changing actual duration of only measure
Fixed in branch 2.2, commit ce9ffd87c1
fix #255646: crash changing actual duration of only measure
Automatically closed -- issue fixed for 2 weeks with no activity.