at end of "Reunion.mscz", slurs no longer follow notes, and pedals lines are offset too far

• Feb 3, 2016 - 16:34

I notice this issuse both on my Windows x86-64 machine, ARMv7-A archlinux, x86-64 archlinux machines.

If I open Reunion.mscz in 2.0.2 release, this is what the final two lines look like:
reunion-windows-202release-annotated.png
note that the Pedal lines for meas 17, 18, 19, 21-22 are all vertically displaced significantly lower than they should be.

Looking at those same lines in a recent nightly (dbd9e84):

reunion-windows-nightly-dbd9e84-annotated.png

Note that the Pedal lines are still displaced. But additionally, the slurs for the ascending base lines are now no longer following the ascending lines. They should look like how they do in 2.0.2 (circled in green). For some reason their ending point is at same vertical position as starting point. So sometime between 2.0.2 and dbd9e84 those slurs got messed up. I should note that I'm able to manually correct those slurs & pedals, resave, reopen, and the corrections remain.

Comments

• Feb 3, 2016 - 17:58

Interestingly in addition to your pedals being in the right location, the pedals on your Mac have short vertical lines at each end, and don't have the word "Ped". And the second bass slur of meas 15 on your mac crosses over the notes (looks like the stems flipped directions but that slur remained the same height).

Reply

• Feb 3, 2016 - 19:43

Be sure you are using the same version of Reunion. The one we ship with 2.0 is not the same as the one from 1.3 - it was updated at some point before release.

I agree the slur issue looks #81321: Slur anchor wrong. Not sure it really is the same root cause, though, since that bug also affects 2.0.2, and apparently goes back as far as cadiz1's nightly build go in 2014. Whereas the issue here with Reunion apparently started some time *after* 2.0.2. However, I do note that even in 2.0.2, if you start moving the last note of the measure upwards, the slur moves downward, which *is* basically the same issue as #81321: Slur anchor wrong. Looking at the code I identified as being responsible for the that issue, I see a change was made back in August of this year, which presumably is why the specific behavior differs between 2.0.2 and the current master. Here is the relevant PR:

https://github.com/musescore/MuseScore/pull/2182

and then a followup commit:

https://github.com/musescore/MuseScore/commit/c900d30268642e2ab43f70d85…

Somewhere in here is the key to all this I assume.

Reply

• Feb 4, 2016 - 15:43

Although it's not a showstopper, it's probably the one layout-related issue I would most like to figure out for 2.0.3 (well, that and a couple I already submitted PR's for) if possible. Clearly, the underlying issue has existed a long time - even before the above "noop" commit, we had #81321: Slur anchor wrong and I can induce the same effect in Reunion by raising the pitch of the last note of the measure. But if the supposed noop changes the behavior, hoepfully that can provide a clue to what the problem actually is.

I will have time over the next few days to investigate further if no one else figures it out first.

Reply

• Feb 4, 2016 - 23:24

Progress report:

I haven't looked into why the "noop" change made the difference it did. And I still don't really understand the code or the intended layout in all the various cases (stems up versus down, beams versus no beam., etc). However, I *can* confirm that commenting out these two lines fixes the problem and so far I can't find a downside:

https://github.com/musescore/MuseScore/blob/5b20a4a374df5074b236742790b…

As far as I can tell, the test only evaluates true in the cases where there is a problem.

Also, I see there is similar code in the section that handles the start point. I can make bad things happen there as well if the slur starts on the *second* of two beamed eighths, with an end point on another pair of beamed eighths with opposite stem direction:

slurpos-start-bug.png

It's not as obviously bad, the the attachment seems pretty randm. Commenting out the corresponding lines in the code to determine start position fixes this, by making the slur attach to the notehead. Not sure if that's desired or not, but it's better than what we currently do.

Wish I knew what the point of these lines was, though, as I still assume there is one. And I wish I knew why the "noop" change had the effect it did. So I'm still working my way through. But if anyone else wants to have a play with it, there's a start point for you.

Reply

• Feb 5, 2016 - 06:06

I found why it's not a noop. Before my commit we had this line which didn't make sense. https://github.com/musescore/MuseScore/commit/c900d30268642e2ab43f70d85…

So my love for symmetry took over and I replaced it with the following which does make sense but then broke it.
https://github.com/musescore/MuseScore/commit/c900d30268642e2ab43f70d85…

#81321: Slur anchor wrong only happens to be in the same area but it's probably not linked.

Reply

• Feb 6, 2016 - 21:16

The pedal lines appear to be "correct" - that is, the version of Reunion in question *does* have manual position offsets that result in those positions, and it *does* have the "Ped" symbol, and it does *not* have the hooks. The actual 1.3 version loads better; I suspect that it was lasconic was looking at. But the version shipped currently was saved with an experimental pre-release build of 2.0 and things were still in flux in terms of how pedal lines would be stored.

I suppose what this says is that we should update the demo scores. Or scrap them, since most people will probably never notice them. Or make them easier to find.

Reply

Do you still have an unanswered question? Please log in first to post your question.