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

• Jun 16, 2020 - 11:33
Reported version
P0 - Critical
S2 - Critical

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: a3e23d6

Huge spaces have developed between the music staves and associated tab staves in most, but not all, scores. See attached files. The bug is apparent in "tarrega_gran_vals", but not in "auber_on_yonder_rock" (Note: there is also a bug affecting scaling: see #306819: 3.5-dev: Scores are over-scaled (compared to 3.4.2)).

Attachment Size
tarrega_gran_vals.mscz 36.74 KB
auber_on_yonder_rock.mscz 25.04 KB


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.

Title 3.5-dev: Huge spaces between music staves and tablature Huge spaces between music staves and tablature with offset rests in voice >1

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.

Priority P0 - Critical

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 will take a look, but one way or another, definitely we'll get something figured out.

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.

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.

Fix version