Ties can collide with staff lines
1. Open attached score (produced in 2.0).
Expected result:
Actual result:
Notes: The expected result is approximate, but potential. From top tie to bottom: The vertical offset in the first set of chords is 0.05sp and 0.45sp respectively - the second set reverses this order.
Page 61 of 'Behind Bars' states: "The curve of the tie should be sufficiently round to be conspicuous through a stave-line. Ideally, a shallow tie is 1-1½ stave-spaces deep.
The centre of the curve should not coincide with a stave-line, since the tie then becomes less conspicuous. This means that ties drawn within the stave will usually cut through a stave-line:
[Example]
Ties are generally confined within one stave-space when they are very short, and when they must be flattened to avoid another part:
[Example]
"
Using MuseScore 2.0 Nightly Build (d9fa175) - Mac 10.7.5.
Comments
It's not just adjacent notes, or indeed even chords at all. You can get the same effect for single notes just tying any two notes together if they are on a line. For chords, it's notes on a space that are the problem.
As a side note, this is not directly related to my recent change to enforce a minimum tie length. But now that ties are long enough to see by default, it would be nice if we went the rest of the way figured out a way to avoid staff lines - either by increasing the arc or by adjusting the y offset.
I'm working on this - the last (!) of the layout-related issues I have on my list of things I wanted to see taken care of for 2.0. Here is my code thus far:
https://github.com/MarcSabatella/MuseScore/tree/24895-tie-height
It's pretty straightforward for MuseScore to detect when a tie is conflicting with a staff line and to draw the tie higher or lower as appropriate. That much I have working. It's actually the only thing I've done with layout that is similar to what Sibelius does in "magnetic layout" - calculating a natural position for an element but then overriding that if a collision is detected.
But this raises a question of what should happen if the user then tries to edit the tie - should edits be made relative to the natural position or the new "magnetically adjusted" position? It is of course possible that the edits will change MuseScore's opinion of whether magnetic adjustment is needed. A further complicating factor is that subsequent layout changes may also result in a change of opinion here.
So I think it is important that whichever position edits are made relative to, this is locked in upon edit - that is to say, edits become absolute rather than relative. It also seems we want to make a good choice here as we may be setting a precedent for how how similar situations should be handled in the future.
I'm open to thoughts. Sibelius seems to make edits relative to the magnetically adjusted position, but it shows you a ghost image of the natural position while you do this (not sure why, but I can imagine it being useful). I don't have enough experience with it to say how well their scheme works. For some reason, I have more of an expectation that the act of editing a magnetically adjusted element will snap it back to its natural position, but I'm probably unusual in that thinking.
And yes, I realize I probably shouldn't be using Sibelius' terminology here.
I probably miss something here. From a user point of view, I would not talk about magnetic layout. For any element in the score, MuseScore computed the best position possible, and users can adjust relatively to this position. The way MuseScore computes the best position is probably of little interest to the user. In this case, it seems MuseScore would compute this best position by trying a position and moving up down if there is a colision. It's more or less the same that MuseScore does for many element, like notehead in second, or your recent change for dots. So from a user perspective, there is only the default 'best" position and the "useroffset" one. The user offset one should derive from this default position. The first "try" position is not useful. Does that make sense?
It does make sense. I am probably overthinking this. As long as we "lock in" this position if the user edits the tie - so it doesn't snap into the original position upon relayout (if number of measures on the line changes, etc) - the effect will be just like it is now. That is, there won't be a guarantee the manual edit will still look good, but it shouldn't look terrible either.
The way I plan to implement this is to have userOff always be calculated and stored relative to the "natural" position, so subsequent layout changes won't invalidate those values. And then continue to make sure that edited ties are not candidates for the auto-adjusting.
After a couple of false starts (never looked at the edit mode code before!) I have it all working very smoothly now. Here is the PR:
https://github.com/musescore/MuseScore/pull/812
Here is my vtest showing the results of the adjustment:
In the above example, the tie on the middle line B in the first measure top staff has been automatically adjusted upward to avoid the staff line. The other ties on the top staff were not adjusted as they were not in conflict with any staff line. On the bottom staff, it is the tie on the C-E chord that was adjusted.
Fixed in 7ec3b0fa33
Automatically closed -- issue fixed for 2 weeks with no activity.