Issues adding local time sig to score with parts

• Mar 18, 2015 - 14:52
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
MuseScore

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.

Comments

• Mar 18, 2015 - 21:13
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.

Reply

• Nov 13, 2018 - 17:48
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

Reply

• Nov 13, 2018 - 19:47

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.

Reply