Wrong beams in parts after TimeSig change

• Nov 23, 2014 - 16:36
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Nightly, November 22 (37a2197) / Windows7

1. « My First Score » → remove 29 measures to keep only 3 measures,
or open this file: Test wrong beams.mscz

2. Fill the first measure with 16th notes.

3. Drag and drop a TimeSig (3/8, 2/4 or other, no matter) in the second measure
1 First Score.jpg

4. Create a part : File → Parts → New → Tick « Piano » → Ok

5. Click on « Part »

Result : all the beams are attached.

2 Wrong Beams Part.jpg

Some variants according the TimeSig dragged-dropped.

Additionnal note :

I am (almost) sure that this issue is related to this other (after some hours of tests...) This is the explanation of the beams issue.
http://musescore.org/fr/node/37071

It is not really a duplicate because: 1) I can reproduce from scratch 2) there is an other issue associated I think (with MM rests and crash): I must checked some points. I am filling a new report for that.

Attachment Size
Test wrong beams.mscz 4.28 KB
1 First Score.jpg 23.35 KB
2 Wrong Beams Part.jpg 28.82 KB

Comments

It would be too long and tedious (it was for me, I spent all my Sunday on this!) by detailing all the steps that have allowed me to understand what was happening with this issue: http://musescore.org/fr/node/37071

Come to the point:
- I have come to realize that the problem was between measures 23 and 24. By removing the measure 24 of the original file: SUITE DO ANDREY (MILAGRE).mscz

and creating parts, the beams in part of Soprano Saxophone are correct.

- I have reduced the score to 24 Measures and two instruments: 24 measures Lead and Saxo SUITE DO ANDREY (MILAGRE).mscz

Again, if you create parts, the S. Saxo part. is false. But, by removing the measure 24, and create again new parts, the beams are correct.

- I got to focus on four measures: 4 measuresLead and Saxo SUITE DO ANDREY (MILAGRE).mscz Same process: same result

- And to my amazement (and relief of not having worked for nothing, as can happen sometimes!), by rewriting from scratch these measures, I was able to reproduce the issues that I described there within minutes (or hours).

First, with two systems: 2 test scratch 4 mesures.mscz

And finally with one only. 3 test scratch.mscz

Finally, note that these two issues (wrong beams in parts, and issue with MM rests) are very former: six months, at least. I can reproduce exactly with a Nigthly of May 19.

Thanks once again for your detective work!

I will add that the problem as described in the first post above goes away if you fill the first of those three empty measures with notes. The difference, I assume, is whether or not the parts being generated contain an mmrest that begins at a time signature change. In fact, if you then delete the note from the score then revisit the part, you see the beam is incorrect again.

I suspect the Group map is being constructed incorrectly in cases where the time signature change is at an mmrest (for linked parts only; I can't get it to fail otherwise), so Staff::group() is returning the wrong beam group.