Issues adding local time sig to score with parts

• Mar 18, 2015 - 14:52
P1 - High
S3 - Major

Ubuntu 14.04, GIT commit: b4b5e28

1) create score with multiple instruments
2) create parts
3) add local time sig to second staff of score

Result: crash

I can fix the crash but it might not be feasible to really make lcoal time signatures fully compatible with parts. Still looking into it, but I can live with this as a documented restriction, even if it means corruptions result from ignoring it.


Title Crash adding local time sig to score with parts Issues adding local time sig to score with parts
Status (old) active postponed

Thanks! My recent fix for other local time signature issues actually eliminates the crash. But it still won't work correctly - the score and parts won't be in sync, as the time signature is maybe *too* local. So you'll see all sorts of bad effects if you try it.

Not sure what's involved in fixing this, but I think the bottom line is, we just can't really support local time signatures in linked parts right now without some more work. I think this will have to wait until after 2.0. Now that time signature properties no longer allows one to "accidentally* create local time signatures, I think very few users will ever run into this.

Frequency Once
Priority P1 - High
Regression No
Reproducibility Always
Workaround No

No crash, but MuseScore shows absolutely irrelevant warning message:
Screenshot 2018-11-13 at 19.47.27.png

A little background to help provide perspective:

Local time signatures (staves with different time signature at the same time, like one staff in 4/4 and another in 6/8) was one of the first features to get implemented for 2.0. It was needed to support the Open Goldberg project. It was probably buggy then but got the job done.
It then got essentially no testing as development continued over the course of the next couple of years and much changed around time signatures in general, thus doubtless creating new bugs with the local time signature feature. It wasn't shortly before the release of 2.0 that we realized how bad things were, and we almost decided to cut the feature out. I didn't want to see that happen, so I went on a mad dash to fix as many issues (crashes and corruptions mostly) as I could, and anything I couldn't fix, I tried to disable the operation that led to the issue. By then we at the point of string freeze, so introducing new error messages was not necessarily a good idea, and in many cases the way the code was written, functions only returned generic error codes so there was no easy way to report better errors without fundamentally restructuring the code in ways that seemed too risky (this is now literally days or in some cases just hours before release). So here and there when I discovered some case the code couldn't handle, I just returned whatever error code was available for that function.

So, that's how we got where are now. A few places where it is still possible to corrupt a file or crash the program, lots more where something that seems like it should logically work won't because we disabled it to prevent corruption but had to settle for some apparently unrelated error message because that was the only choice available at the time. And most of this never got looked at again.