Cross-staff slurs/ties trying to avoid note on wrong staff

For the record, my current PR https://github.com/musescore/MuseScore/pull/4374 does not deal with this. Cause seems to be unrelated to the other cases.

I realize now it's not just cross-staff notation in the sense of notes moved from one staff to another with Ctrl+Shift+Up/Down, internally) - it's also slurs that connect notes on different staves with no cross-staff movement involved. So, it's not about checking staffMove() somewhere, it's about checking the vStaffIdx() probably, and adding in an offset I guess. I thought spanners were generally calculated relative to the system but it seems they are actually relative to the staff - maybe that was changed as part of the "new" layout?

Ties between cross-staff notes have the same issue.

Thinking a little more, I think we have a chicken-and-egg problem. Right now I assume we layout slurs before finalizing staff distance, because in fact the existence of slurs can increase staff distance. So at the point of slur layout, we don't know the relative position of staves.

So my thinking we is, if we detect a cross-staff slur or tie, we should disable autoplace (results would probably be disastrous anyhow) and somehow mark it as needing attention. Then do a second pass to fix up the cross-staff slurs and ties after we've finalized staff positions.

I still feel this would be very important to get right before release, but am not sure it makes sense for me to tackle that right now.

Thanks for looking, and indeed, I don't expect this to be trivial. Might need to pass on this for initial release, but who knows. But do note my pending PR regarding relative layout of articulations & slurs (https://github.com/musescore/MuseScore/pull/4411) which probably touches some of the same code. To me, the articulation is higher priority as it's likely to affect many more scores, even if the current results aren't as dramatically bad.

So I just realize "note anchored lines" (a little-known feature, can only be added from the Add menu, directly connects two notes) actually does work across staves. Badly at first in that when you try to add one by Ctrl+clicking two notes then using the menu, it adds above the top staff of the system regardless of what staves you are actually connecting. But, if you turn off autoplace, the line jumps right back down to where it belongs, and it does track changes in staff distance, so it's basically doing the right thing.

The line gets added as a TextLine apparently but is "owned" by the note, using Spanner::Anchor::NOTE (same anchor type used for ties). Hmm. Probably there is a solution here.

Note anchored lines are handled toward the end of the loop in collectPage() right after ties, but then again a few later as part of Measure::layout2(). Probably we don't need both and could lose the calls within collectPage() itself. I'm thinking it's Measure::layout2() that would be the sensible place to handle cross-staff slurs, but only if we can get cross-staff ties working too (well, "regular" ties but between cross-staff notes), so I'm trying that first.

EDIT: both of those calls are no-ops - they called tie->layout() which doesn't actually do anything. Real layout happens in layoutFor() an layoutBack(), which are called in layoutSystemElements(), somewhat later than slurs but still too soon.

Probably you are discovering similar things, but maybe that's helpful information. I think that's as far as I'm getting tonight.

Surprisingly, while the symptom is very similar (line display above top of system), the causes was totally different. But my PR for that issue fixes both.

No, sorry that was confusing. That PR fixes regular lines above top staff and again more lines above top staff even though cause we're very different. Cross staff slurs are not part of the PR.

For the record, cross-staff notation in general and cross-staff slurs are not uncommon at all in piano music, but given the complexity of the issue and the risk involved with the sort of structural change that would probably be needed to fix this, I agree it is better to live with it for now.

Well, it's the same issue, when it's fixed for one case, it should be fixed for them all. There is work done on this but not yet ready.

Thanks for the offer! You are of course welcome to participate in development however you like - MuseScore is open sour e, after all. See the Contribute menu above, then click Development.

I can say that this particular problem isn't much about math. But one that is is handling cases like a slur between three notes - middle line B, B an octave higher, then back to middle line B. We draw the slur too flat, so the endpoints end up too far from the start and end notes:

We use a bezier curve algorithm to draw the slur with no consideration to how curved it will actually need to be to clear the high B in the middle. I have ideas on how to improve the algorithm to draw a more curved slur in these cases, so we'd get something more like this:

But I am not confident on how to get the math right (hard to admit for a math major, but my specialty was abstract math, not applied...)

Sorry for being confusing. I get these are different. I just meant, if you're looking to help, and your specialty is math, it's the curvature issue that we could use help with. The cross-staff slur problem I think we have something of a handle on, and it's not a math problem at all but one of the data structures and algorithms, so perhaps harder for a newcomer to the code to deal with anyhow.

There is indeed no way to get this right currently. There has been some work to try to address this but I think it's not ready. Absolutely a very high priority.

Relates to #285233: [EPIC] Cross-staff notation issues

I'm on it, close to a solution.

The following PR should fix things for both slurs and ties, both for cases where the notes themselves are cross-staff and when they are simply on different staves "for real". Ties work whether one or both notes are moved. It's not a big change, and shouldn't affect layout in any cases except cross-staff, except for fixing a small glitch with the layout of ties between enharmonic notes along the way.

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