Huge spaces between music staves and tablature with offset rests in voice >1

A quick glance at one of the test scores from another issue report shows the skyline is way off. Notes on the tab staff have their "line" set to -10000, and I assume that's the cause of it. Not sure why; even in this same score newly entered notes appear normal.

Scratch that, it's not the notes that are the skyline problem - it's the rests. I guess -10000 is the normal "INVALID" line value for notes on tab staves, they use fret & string instead.

Not sure exactly where this happened, but I'm continuing to investigate.

Seems to be the new code to automatically offsets rests to avoid notes in other voices, it is getting tripped up by the (correct) invalid line value. Fix will presumably be to use string instead in this calculation for tab staves.

That much is trivial, but there are also some hard-coded assumptions that staves have five lines, then some corrections for more or fewer lines later, and this code isn't working right with the new alignment algorithm either. Not as crazily bad as the issue here, but anyhow, both issues should be solved together. I'm hoping the author of the alignment code in https://github.com/musescore/MuseScore/pull/5897 will take a look, but one way or another, definitely we'll get something figured out.

Thanks for working that out. I will have a look.

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

Fixed in branch 3.x, commit 8489bb284f

Fix #306821: The collision avoidance of rests now takes into account TAB staffs and different number of lines.

Fixed in branch 3.x, commit 14aa080d2b

_Merge pull request #6224 from tobik/306821-tabstaff-and-stafflines-for-restcollisionavoidance

Fix #306821: TAB and number of lines in collision avoidance of rests_

As far as I can see now rests that had been offset to avoid collisions now that that offset in addition to the one that does not automagically gets applied resulting in rests that are even farther away from the staff.
Maybe that algorithm should ignore rests that have manual offsets already?

In that case the rest would jump from the calculated offset to the default offset at the first manual offset and from then move step by step. This is not what I would expect it to do. Especially if small correction to the auto-position should be applied. Isn't it better to select all rests and reset manual offset.

Well, that then means it won't look good in 3.4.2 anymore
And means manual intervention needed for all such scores in 3.5

Not a fault of this PR though, is the case in 3.5 Beta already

It is basically the same as with all auto positions from ms2 to ms3.

True, but this time for 3.4 to 3.5 and as such very much not to be expected.
Currently for a score with rests that collide the decision needs tpo be made whether they look good in 3.4.2 and lower (by manually offset them) or in 3.5 and higher (by not offsetting them).

If the collision avoidance would ignore those with a manual offset, both cases would be covered cleanly

I agree it's important to improve compatibility here. One method, of course, is to make this whole adjustment optional, perhaps controlled by a style setting as it is for the new chord symbol alignment feature. But, I think we can do better here.

Ideally, I think manual adjustments would work similarly to how they do when autoplace moves staff text (for instance). The offset is calculated based on the original default position, but you only see the effect of the offset once it is greater than the adjustment perform by autoplace. This means if you click a staff text that has already been moved higher above the staff by autoplace to avoid a note above the staff, then start pressing Up to move it up, you can see the offset increasing (technically decreasing since it's negative) in the Inspector, but nothing happens in the score until you reach the actual amount of offset already applied to the note. And yet, you can also force a staff text back toward the staff - even to collide with the note below.

No reason rests shouldn't be expected to work the same way. Not saying this was the ideal way for autoplace to have worked in the first place, but it's not bad and we're all used to it by now. The way this is implemented in autoplace has to do with the "skyline" calculation and the "minimum distance" property for each element, and I don't think that would translate directly.

But taking autoplace as a model, I do think there is a pretty simple implementation that would work well enough here:

1) go ahead and honor manual adjustments relative to the original default, as @Jojo-Schmitz suggests
2) to avoid the jump that would happen the first time you press up or down, you could intercept that code and "rebase" the offset at that time

Step 2 to me is optional - if it's easy, go for it, if not, "meh". Yes, a slight surprise when you first do a manual adjustment but I could live with it, and it could always be revised later without affecting compatibility.

But then it wouldn't be possible to move the rest toward the note. Or should a positive value move it that direction?
So if manual adjustment is
a) positive: move toward note
b) 0 > default position: default position
c) < default position: move away from note

Doing it the way I suggested absolutely allows you to move the rest toward the note. If you leave out step 2, it happens already without a second thought. If you tackle step 2, I don't think you need to special case the direction at all. Simply check when doing an offset change if the property is currently styled (meaning has not been changed from the default). If not, just process the offset change normally. If the offset was currently styled (which will mean, in effect, it is 0, but better to check if it is styled), you need to somehow calculate the "true" offset and subtract that from the requested offset.

To me, not really worth the effort, and it's pretty easy to get stuff like this wrong in terms of unintended differences between adjusting by keyboard vs mouse vs Inspector.

The bottom line is that a manual offset needs to mean the same thing in 3.4 and 3.5, otherwise compatibility is shot. It's OK if scores created in 3.5 that rely completely on the automatic adjustment - no manual adjustments - end up having collisions in 3.4, that's to be expected. But someone who applies manual adjustments in either version needs to be able to rely on it looking the same in the other version.

I tried moving the text as described by Marc. With keyboard up/down it is pretty smooth, but trying the same with inspector is confusing:
1. Decreasing the "Y-Offset" one step moves the text by 0.5 sp as expected but at the second step it jumps to the position without any automatic offset.
2. Reset "Y-Offset" to style default moves the text, but not to the correct position.
3. De- and re-select the text it now has a "Minimum distance" not anymore style default.

That's not good. Why is keyboard vs. inspector movement that different?

It's a combination of two factors. One is that in a sense the Inspector is lying to you about the true offset - it's showing the offset as set by the user, but unless autoplace is disabled (either directly or by setting a negative minimum distance), it may not reflect the true position. So after you start adjusting in the Inspector, it does take on the true position. This is complicated by the fact that the Inspector has a limitation where the code cannot update the values displayed while they are being edited, which is why you need to deselect / reselect to see some changes. It's definitely not ideal, but overall works well enough for most cases, certainly a heck of a lot better than when 3.0 first came out and people complained like crazy that autoplace made it hard to do manual adjustments.

Anyhow, I wouldn't worry about any of that, just try to get rests working reasonably. As I said, I really don't mind if there is a jump on offset change, and chances are you won't be able to make it perfect. if you are, great! But I don't think anyone expects that here.

For backward compatibility (Step 1 of Marks suggestion)
https://github.com/musescore/MuseScore/pull/6243

Fixed in branch 3.x, commit 2ea02d071f

Fix #306821: For compatibility of existing scores apply automatic collision avoidance to rests only if y-offset is unchanged

Fixed in branch 3.x, commit 8565eb1da9

_Merge pull request #6243 from tobik/306821-restcollisionavoidance-compatibility

Fix #306821: For compatibility of existing scores apply automatic col…_

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