Change time signature when the measures of entire score are joined causes a crash

• Sep 30, 2017 - 15:49
Reported version
S3 - Major

2.1 version / Windows10

1) "Untitled" score
2) Ctrl + A
3) Edit -> Measure -> Join selected measures
4) Change the time signature (drag and drop or double click)

Result: crash

. Same issue with 2.2 dev. and former versions.


In reply to 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

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.