Slur anchor wrong

For the record, it isn't about dragging per se. The slur attachment is just plain wrong for this particular case regardless of how tpu wnter the last note. Low notes result in high slurs.

I note the same behavior with this Nightly on May 19, 2014: 56177c3

Apparently, and except error, the conditions (or some conditions, to check) are:
- the first note must be = or > to the B into the staff (under eg an A, works as expected)

- the last note must be the last one the measure, and a 8th value or lower (works with quarter note)
- three notes minimum (eg three eigth notes) and more must be involved (works with two notes)
May be some others?

I don't pretend to understand the slur positioning code, but it seems to me numbers look basically reasonable through Slur::slurPos() until right here:

https://github.com/musescore/MuseScore/blob/7885dafe68c966e5e44205632c7…

Whatever these two lines are trying to do, I think maybe it shouldn't be doing it here, and commenting them out does fix this, but presumably they are needed for some other case. So probably there should be some additional clause(s) added to the test.

I've finally figured out what is going on here. In cases where the stand and end notes have opposite stem directions, the code is trying to "float" the start and end points of the slur along stem. So for instance:

See how the start point of the slur moves higher up the stem as the second note goes up? That's a good thing, I guess. However, the code doing this doesn't work right in a number of cases, leading to the problem we see here:

This also leads to the problem in Reunion described in https://musescore.org/en/node/96816. I can make a number of other things go wrong as well:

The bug has to do with incorrectly determing the range we are allowed to "float" within, as well as incorrectly determining when it is OK do do the floating in the first place. It should be no problem to fix, but I'm not actually sure yet what the proper behavior should be in a few cases. For instance, is it ever OK to start the slur in the middle of a chord, like this:

That particular example doesn't look so good, but I'm not sure what rule to follow is. I'll pore through Gould and whatever other references I can find and see if I can come up with something reasonable.

FWIW, Gould p. 111 touches on this, although it doesn't really go into nearly as much detail as I might like. But the basic principle is: when the first start and last chord have different stem directions, try to make the slur follow the direction of the motion. So if the last note is higher than the first, the slur should basically slant upward (downward if the last note is lower than the first). She describes this as moving one end of the slur inward (on the assumption that the default would have been to place it outisde the stem). In our code, we actually default to having the slur clsoe to the notehead, so we are actually trying to move outward toward the end of the stem as necessary. So the slur in my example above *is* wrong; the slur should slant downwards and thus start just above the top note of the chord.

I'm adding comments to the code as I go so hoepfully this will all be clearer next time we need to look at any of this. I hope to have a PR in within the next day or so.

The following fixes the problems discussed in this issue:

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

To show the effect of the changes, here is the vtest I added, as rendered (incorrectly) in 2.0.2:

Note in particular the bottom staff - the first and last measures illustrate the problems discussed in this issue.

Here is the same file rendered with my PR:

The problem in the first and last measure of the bottom staff is fixed, and there is also an improvement in the third measure of the top staff.

I'm very much looking forward to this. How far does this go in terms of slur positioning, though—for example, in the bottom staff, third measure, what if the half note C was an octave lower? Is there still work to be done on this sort of thing?

How odd—the last measure on the bottom staff renders correctly for me with 2.0.2.

EDIT: As does measure 3 in the top staff.

That shouldn't be possible. Are you recreating that example from scratch or using the version from my PR? If you are doing it from scratch, can you post the specific score you are using, and show a screenshot of how it looks for you?

As for your question about how far this change goes, I didn't implement any new magic collision avoidance, if that's what you are asking. Slur layout continues to just be about the first and last note, positioning the end points for the slur somewhere between the notehead and end of the stem as appropriate. If the slur would cross intervening notes, that's something you still have to adjust for manually. Aside from that, though, I'm not understanding what effect you are thinking moving the half note C *lower* would have. Moving it an octave *higher* definitely causes a collision.

OK, weird, now that last measure renders correctly in 2.0.2 for me as well. Investigating...

Edit: if you flip the stem of the first pair of eighths down, you should see the bug again.

Fixed in branch master, commit aee7cd151f

fix #81321: bad slurpos with mixed stems

Fixed in branch master, commit 2ac74a5dc7

Merge pull request #2379 from MarcSabatella/81321-slurpos

fix #81321: bad slurpos with mixed stems

Fixed in branch 2.0.3, commit d0f6cab232

fix #81321: bad slurpos with mixed stems

Automatically closed -- issue fixed for 2 weeks with no activity.