Entering local time signature causes score corruption if incompatible with global time signature

• May 12, 2020 - 12:35
Reported version
3.4
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

Referencing the already provided score,
Starting with all instruments in the 9-8 time signature in the first partial measure, and the Timpani showing 3-4 time signature in the 2nd measure-
(FYI the first measure has had it's duration changed using Measure Properties to "Actual" 1-8 time signature.)
From the Time Signatures palette, CTRL+Drag the 3-4 time signature onto the Timpani first measure time signature.
Result: MS accepts the change, Timpani now has 3-4 t.s. in the first measure. The other staves remain at 9-8.
Save the score and re-open it: an error message window presents, indicating the corruption in the Timpani line- Click "Show Details", result: "Measure 1, staff 25 incomplete. Expected: 1/8; Found: 3/16"
Please see forum topic here:
https://musescore.org/en/node/305299
Acceptable fixes would include allowing the local time signature change but somehow avoiding the corruption OR disallowing the change with a pop-up window and message indicating the change is not permitted.

Attachment Size
Wagner makes me want to invade Poland.mscz 101.04 KB

Comments

I just encountered another similar corruption in the same score and will update the Issue Tracker accordingly.
Action: on a score that opened with no error messages, at Measure 99 CTRL+Drag a 9-8 time signature from the Palette to the Oboe I part, and repeat for the Oboe II and Oboe III parts. (This is to add local time signature changes required in the source score.) MS accepts the changes. Save and close the score.
Please note that at Measure 99, the Oboes had been previously changed from 9-8 global to 3-4 local time signatures at Measure 91. The action here was returning them to the previous 9-8 time signature.

Result: when the score is re-opened, a corruption error message occurs.
Summarizing the Details of the corruption message:
Measure 100, staff 8 incomplete. Expected: 9/8; Found: 27/16
Same for measure 100 staves 20 and 21.
Measure 101, same error for staves 8, 20 & 21
Measure 102, same error for staves 8, 20 & 21

Please note that previously (Measure 91) a large number of other local time signature changes were made, as per the source score. The easiest way to accomplish was to add a Global 9-8 time signature at that measure, (since the Timpani was being changed from 3-4 to 9-8 at the same place that the Oboes were changed from 9-8 to 3-4) and then change the Oboes.

The attached "measure 99 key change.png" shows the measure where the Measure 99 key change takes place and also includes the IMSLP document number should someone need to access the complete source score.

Creating a new score with an initial t.s. of 9-8, I added various new elements until Test 14 produced a corruption message very similar to what we've been seeing with the score that originated this issue.
Test 13, no corruption message; Test 14 corruption message. The message is-

"For measures (17 through 41), the message is "staff 2 incomplete. Expected: 3/4; Found: 2/2"

The difference between the two is that at Measure 17, the upper piano parts upper staff was changed to 3-4 while the lower staff was left at 9-8.

I was able to (with a large amount of effort) remove the score corruptions and time signature issues. After deleting the staves that had corruption warnings when the score is loaded, I created new staves to replace the deleted ones and re-populated the content.
The work-around was- When it is necessary to change the local time signature for a limited number of staves, it is best to continue with note entry on the staves that do not require a time signature change and do not make the local time signature change at that point. Once several pages of content have been entered on lines in the original TS, then one can go back to where the local time signature change needs to be made, make the local TS change, and continue with note entry in the new TS lines.
My theory (I don't know if this makes sense from a coding perspective) is that when a local TS change is made, there must be enough "free space" (or "tics"?) after that measure to allow MS to completely implement the TS change. If the score ends (no new empty measure available) too soon, MS isn't able to completely implement the local TS change.

I think MS should have an intelligent time scaling algorithm when using local time signature, e.g., scaling the duration as 1:1.5 when 9/8 vs 3/4 or 6/8 vs 2/4 or 3/4 vs 2/4 etc. This is very common notation lasting around 400 years, so Musescore uld allow users to conveniently enter anything from traditional notation.

Severity S3 - Major S2 - Critical

And I changed the priority to Critical (I think even Blocker is suitable), because when Mike320 was doing the attached Vaughan Williams symphony no. 6 which I'd like to transcribe in braille, he had to give up around measure 40-50, where there are very strange timing problems and are even impossible to get rid of. The most frustrating thing is, you have to delete a certain length of passage in whole and re-enter them in another order, very complicated, and it's not engraving, it's a torment. I don't like entering fake text time signatures and fake tuplets--this is not musical, but tricky. Sibelius has this behavior, and it's a disaster when making braille transcription with such Sib scores. Musescore is the first notation software allowing local time signatures. So I think it should become a clean function.

Haipeng

Attachment Size
Vaughan Williams Symphony #6.mscz 90.38 KB

In reply to by hhpmusic

I totally agree with the migraine-inducing consternation factor. Although in my case I was eventually able to make it work using real local time signatures instead of fake text etc., my work flow was basically: with a non-corrupt score, add a new local TS and a few notes in the measure; save with a different name; close the score and re-open to check for a corruption message. If no corruption then fine, continue; if corruption go back to the uncorrupt score and try again. Often the “try again” was to (at the where the local TS change caused the previous corruption) add a new global TS at that point that was the same as the global TS already in effect. Then, add the new local TS and render the global TS elements not visible and disable courtesy TSs. Since disabling courtesy TS is at present only available globally then use text to create a false courtesy TS on the new local TS if called for in the original IMSLP score. Then repeat as necessary a dozen or more times as new local TS are required. At least it worked though it was a lot more work than should have been required.

Question - often the new local TS could not be copied/pasted (or pressing R to repeat a measure), giving an error message about tuplets not being able to cross bar lines. This was another impediment to work flow. Is there an open issue on this problem?

It is possible to use local time signatures and make things work eventually (at least with one voice). I gave up when I kept getting a corruption because the oboe has two voices and got tired of starting over. I'm sure if I wanted to do this score bad enough for some reason I'd figure out the proper order of entries but it shouldn't be so hard.

The attachment (Vaughn-Williams score) in https://musescore.org/en/node/305320#comment-1017027 can't be found, that might have been the week the site went down? Anyhow, I'm not convinced it's the same issue as described here. The issue here is specific to local time signatures in pickup measures or other measures in which the actual duration doesn't match the nominal duration - it's not about local time signatures in general. And really, there is no obviously correct thing that should happen in this very special case - the math just doesn't work out, so anything we did would be a lie. It shouldn't cause corruption, to be sure, but in order to fix, we'd need agreement based on some real-world examples as to which mathematically incorrect but non-corrupt result to produce.

Indeed, the corruption in that score seems unrelated to the issue here, none of the affected measures have had their actual durations modified. Again, the particular bug being discussed in this thread has to do with measures - like pickup measures - where the actual time signature does not match the nominal. In those cases, it may be mathematically impossible to do the normal expected thing with local time signatures, so we still need to determine what the most reasonable thing to do instead would be.

In the Vaughn-Williams example, these are ordinary measures otherwise, no modification to actual duration was made. They are corrupt indeed, so no doubt some bug led to this - and that bug would indeed probably be judged more serious than the one here that only affects cases that are mathematically impossible to solve anyhow.

So, if someone can figure out how to reproduce the problem in the Vaughn Williams example, please open a new issue with an uncorrupted version of score and precise steps to reproduce the problem from there.