Double barline not synced in a score with parts

• Dec 30, 2018 - 10:47
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore
Tags
barlines

OS: Windows 7 SP 1 (6.1), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4839, revision: cf1f5ce

Steps:
1) SATB template
2) Create parts
3) In main score, insert double barline (eg first measure to mark an anacrusis)
Result: the double barline is not synced in parts

Test file at this step: double barline.mscz

Workaround: insert double barline first in main score before generate parts

Severity? Always the lack of "Normal" option :(

Comments

• Dec 30, 2018 - 18:30

I'm away from my computer, but I'm guessing this bug is main score to parts direction only. If you drop a double bar line in a part, I take it it appears in main score, right.

Reply

• Dec 30, 2018 - 18:52

But I must say that I seem to notice some inconsistent behavior, perhaps in interaction with other things (repeat barlines eg, but curious, so I'm not really sure for the moment, it would be necessary to check further.)

Reply

• Dec 30, 2018 - 19:22

Same problem with 2.2.1 on Linux/Leap and as far as I remember with 1.x on Linux also. Behaviour appears to system text as well. Both issues do appear randomly only.

Reply

• Jan 25, 2019 - 18:37

MuseScore 2.3.2 seems to have only have the problem with the special barlines "Tick 1 span", "Tick 2 span", "Short 1 span", "Short 2 span", and also when dropping an end-start-repeat the other linked scores will only get a end-repeat.

Reply

• Jan 25, 2019 - 19:45

I was trying on a fresh score with a part.

Anyway, I'm debugging and finding that in undoChangeBarLineType() when iterating over linked barlines:

                                    for (ScoreElement* ee : e->linkList()) {
                                          ee->score()->undo(new ChangeProperty(ee, Pid::BARLINE_TYPE, QVariant::fromValue(barType), PropertyFlags::NOSTYLE));
                                          ee->score()->undo(new ChangeProperty(ee, Pid::GENERATED, false, PropertyFlags::NOSTYLE));
                                          }

But the problem is those barlines don't have anything in their _links, so e->linkList() just returns a the one barline that actually gets changed.

Trying to see what happens when drop onto a previously-edited barline...and also found bad behavior. if I have a new score with a part, and drop an end repeat, and then drop a double-barline on that end-repeat, then the double-barline is applied to the current score, but the linked score gets a normal barline. If I then press undo, and then drop a double-barline on that end-repeat, then the double-barline is applied to the current score, but the linked score keeps its end-repeat.

Anyway, I'm thinking that instead of iterating over the barline's linkList() which doesn't seem to actually hold a list of its linked barlines, I'm thinking should iterate over the measure's linkList(), since the measure's linkList() seems to actually be valid. I'm guessing links aren't kept track of for barlines.

Reply

• Feb 3, 2019 - 09:28

The workaround does not work (Workaround: insert double barline first in main score before generate parts).

Randomly, some double barlines are not generated.

See attached file. 1/ Remove the parts. 2/ Create the parts. 3/ Some double barlines are not be there.

Attachment Size
Moment for Morricone trio.mscz 75.12 KB

Reply

• Feb 10, 2019 - 12:10

So, after a thorough investigation (all tests with SATB template), the crux of the story occurs in beginning August 2016.
Basically, the double lines have worked (synchronization in parts) in branch 3.0 until that time.

A few adventures here and there (a crash by adding them on June 14, fixed on July 8). Also: the characteristic of this whole period is that the double line appears as such when the MM rests were disabled in parts, but only displays a single line when the MM rests were enabled. However, this is probably (?) a minor point.

The improvement on this point occurs on August 4 since this nightly, 1736346 (not checked the exact commit).
And now, everything is working really well. Display and synchronization.
Unfortunately, things will start to go wrong soon after.

On August 6, the "Mark irregular measures" feature is implemented in bcb4cf3

It is then noted that this is also displayed with the MM rests in parts. Like this:
soprano.jpg

Then, noted also that when disabling the MM rests , an unexpected clef was there - image below.

mauvaise clef.jpg

These two points were therefore fixed with the next nightly: 32c1a9e

There is two commits included in this nightly.
This one (for the clef) : https://github.com/musescore/MuseScore/commit/5df2a87cc0c83525ab7d0ed0b…
And so: https://github.com/musescore/MuseScore/commit/32c1a9eac1c15ca41fe21350b…

Don't know which is the trigger (one or/and the two commits?), but from then on, it no longer works (and it's still the current behavior): double lines are displayed in main score, but not in parts.

soprano cassé.jpg

Reply

• Feb 10, 2019 - 18:12

Thanks for the investigation! if we had a "bug bounty", this would be very high on my list :-) The barline code is very complex and I don't feel comfortable making changes here myself at this point.

Reply

• Mar 29, 2019 - 17:59

I decided to look at this after all, and I think I mostly have it fixed, along with a few other issues involving multimeasure rests and also barline spans. Hoepfully a PR soon.

Reply

Fix version
3.1.0