changing to a 'compatible' timesig behaves as if being a local time sig
- new score, from closed score SATB+Piano template
- create with 6/8 time sig
- now drag (not shift-drag!) a 3/4 timesig onto the 1st measure
expected result: all staves change to 3/4
actual result: only the staff you dropped the 3/4 on changes, as if you'd have used shift-drag
self-built 9ab4e3e, Windows 7 (Enterprise, 64bit)
Comments
As far as I can tell in a brief analysis, the problem is not related to my recent changes, but stems from this line:
https://github.com/musescore/MuseScore/blob/9ab4e3e7654b34a26a64a4d1b08…
ots->sig() (the old time signature) should probably not be showing up as equal to ns, since one is 3/4 and the other is 6/8. But they are. I guess we need to use the "identical" test rather than "==" if we want this to work as expected (although perhaps that breaks something else). Will investigate more later.
In particular, I wonder if the test for "==" rather than identical has something to do with 4/4 versus 2/2 versus common versus cut and some of the issues we've had changing between them.
The good news is, the key signature is not really "local" in the sense that is likely to cause problems: "stretch" is still 1/1. Changing each staff individually should work fine. As should changing to something incompatible first, then changing to the desired signature. But still, would be good to fix this. First step I think is understanding if there is a reason it is the way it is.
Seems fails only with 6/8 "original" and change for 3/4 in the score. Works with other change time sig: 2/4, 4/4 and so on
It works also if the "original" key signatures are 9/8 or 12/8 (->change for 3/4 ok)
Using identical should fix it. The first case is really usable only if a property of the timesig change but not the fraction.
Fixed in df0d65c344
Automatically closed -- issue fixed for 2 weeks with no activity.