Barline of added instrument exceeds stave height

• Feb 20, 2015 - 12:32
Type
Functional
Severity
S4 - Minor
Status
closed
Project

1. Open attached score (produced in 2.0 beta 2).
2. 'Edit'>'Instruments…'.
3. Add Piano.
4. 'OK'.

Result: The barline exceeds the stave height.
Barline of added instrument exceeds stave height.png

Using MuseScore 2.0 Nightly Build 12b4b1c - Mac 10.7.5.


Comments

I can't reproduce in a score created from scratch, so it might be a bug already fixed or some perculiar artifact of this score. If you reproduce from scratch, please provide precise steps, otherwise, I recommend we close, or at the very least downgrade to minor.

Status (old) needs info active

I can reproduce in a new score.

1. Create score that mirrors the original one.
2. 'File'>'Save'.
3. 'File'>'Close'.
4. Open the score.
5. 'Edit'>'Instruments...'.
6. Add piano.
7. 'OK'.

Using MuseScore 2.0 Nightly Build d9e3e93 - Mac 10.7.5.

Confirmed, even without *exactly* mimicing the original score. The key is the save/reload. So, here are precise steps:

1) new score from scratch, choose Electric Guitar[Tablature] as only instrument
2) save
3) reload
4) edit / instruments
5) add piano

Result: same basic result

Inspector reports the span as 0 - 10 rather than 0 - 8 as it should be. Unlike some similar issues in the past, this does not fix itself on another save/reload, But you can fix it manually (doube click/drag).

Only affects grand staves.

I'll look into it.

So, I understand something of the cause, enough to make me concerned there might other effects that are probably worse than this one..

First, when inserting the new instrument, the part is inserted at the *beginning* of the part list. That happens here:

https://github.com/musescore/MuseScore/blob/master/mscore/instrdialog.c…

This causes its staves to be similarly inserted at the beginning of the list, here:

https://github.com/musescore/MuseScore/blob/master/mscore/instrdialog.c…

This would be fine - staves are sorted later - except the barline span for the piano staves is calculated when we add the first staff. Because we haven't added the second piano staff yet, the code in adjustBracketIns() that calculates the bar line span sees the guitar tab staff (which is below the piano staff because we added the piano staff at the top) and takes *its* line count to be the line count of the second piano staff. So, wrong number of lines.

Right above that is where bracket span is set, and I kind of suspect this same type of problem might have to do with a number of issues we have to bracket spans when adding / removing staves. Here is one:

1) load same score saved in above
2) instead of adding one piano instrument, add three (select piano, press "Add" three times)
3) OK

Result: a mess of overlapping brackets. I suspect this is the same basic cause as a couple of existing issues in tracker.

Both of these problems date to the beta 1 or earlier. If I remove the call to adjustBrackIns() from undoInsertStaff(), both of these problems are fixed. It seems the barline "to" info was intitialized as well as it needs to be in the Staff constructor, and the bracket and barline "span" info in Staff::init().

The downside of this is that adding a staff to an existing multi-staff instrument will not automatically extend the bracket - you'll have to do it manually. To me, a fair trade. We could probably also add some sort of flag to only do it when adding staves to an existing instrument, not when adding a new instrument.

I will submit some sort of PR for consideration / discussion.

Status (old) active patch (code needs review)

Here's a PR that just removes the adjustBracketIns() call. Doing more seems like it would be more work than it's worth right now.

Would have been nice, but no, the change I made here only affects *inserting* staves, not changing type.

I suspect there is a similar issue involved, though.