Continuous view: Key change forces double barline

• May 27, 2019 - 16:55
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

3.1-rc

Create a score and look at it in continuous view. Insert a key change (either global or local) and a double barline appears before it.

When you switch to page view, the barline is normal.

As a workaround you can insert a new single barline after you change the key and it will be displayed properly.

I haven't tested previous version for regressions, but I wouldn't hold up release of 3.1 over it.

Comments

• May 27, 2019 - 18:56

This is deliberate, I think. It's proper for double bars to appear before key changes, and we actually insert them automatically in page view too, in some circumstances (the courtesy at key sig end of system). As I recall, we made it optional for key changes in page view so user could have the choice, but really, there is no pressing need for continuous view to not do this IMHO.

Reply

• May 27, 2019 - 20:01
Status by design ⇒ active
Priority ⇒ P2 - Medium

To me it's still worthy of further discussion, so I'm reopening. The idea is to provide control in page view where it matters but also make sure the cases where you aren't really control (when a courtesy key signature is added for you) get handled the most standard way, and that's definitely with a double bar. Continuous view really could go either way. An advantage of the proposed change - and in particular the proposed PR - is that it also improves the drawing of start repeats. In page view, we skip the end barline for measures immediately followed by a start repeat, but in continuous view, we don't, for the same reason we draw double bars before key signatures: we treat measures in continuous view as if they are all "end of system".

It is also worth considering whether the default should be to add double bars before key signatures in page view as well but give the user the option to override. That would be easy enough to, but an issue I foresee is there are places in the code where we kind of assume "generated" means the same as "normal" barline, like when we try to decide what resetting a barline should do. Maybe it would work to just mark the barline generated and let createEndBarLines take it from there, but definitely testing would be in order.

Reply

• May 27, 2019 - 20:33

One thing that I think needs no discussion is that the same thing happens in both continuous and page view, so there is a bug here. There is no need for a mandatory double bar line before a key change. The one I found it on was when I changed instruments and inserted a local key signature so it would show properly at the instrument change. I definitely don't want a forced double barline there.

Reply

• May 27, 2019 - 21:10

Well, again, originally the discussion that led to this was that continuous view should do more things automatically since there are fewer decisions one can/should make there, so it was not a bug but by design. And there are many times, after all, when something that makes sense in page view doesn't in continuous, so that isn't a bug in itself. But, it is definitely worth revisiting, and it's a design that I would agree should be changed.

Reply

Fix version
3.3.0