Too much space allocated around tab staff with"beamed" notes

• Dec 21, 2018 - 20:28
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

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

Open the attached file (created in 2.x) and take the reset. Select the accent in measure 6 and decrease the Y-offset.

Expected result: The position of the previous system should have priority and block the progress of the dynamic.
Actual result: The element continues to push the previous system upwards.

Attachment Size
chansonette_2.x.mscz 32.94 KB

Comments

• Dec 21, 2018 - 23:05
Title Element can cause spurious increase in system distance ⇒ Too much space allocated below tab staff
Priority ⇒ P1 - High

That's not how it works - if you ask for a symbol to be a certain height above the staff, MuseScore does what you ask. It also tries to avoid collision with the staff above. If you want to avoid the collision, turn off autoplace.

But there is a bug here, and that is that we start increasing system distance before the accent actually hits the staff above. Apparently we allocate a border around tab staves that we don't around standard - change the bottom staff to standard in Edit / Instruments and you'll see you're allowed to raise the accent all the way up until it almost touches the staff.

Reply

• Jan 7, 2019 - 21:48
Title Too much space allocated below tab staff ⇒ Too much space allocated around tab staff with"beamed" notes
Priority P1 - High ⇒ P0 - Critical

The cause appears to be that we are erroneously including the non-existent beam in the skyline. This is an issue only for beamed notes - in a debug version of MuseScore 3, this is clear as day if you enable Debug / Show Skylines:

beam-skyline.PNG

Reply

• Jan 22, 2019 - 17:54

As noted in the comment there though, the bugs are completely unrelated so no particular reason from an implementation standpoint they need to be considered together. PR's for them can and should stand alone.

Reply

• Feb 19, 2019 - 23:02
Status active ⇒ PR created

In my investigation, it seems this is only a problem for scores imported from 2.x using a custom tablature style and not then saved in MuseScore 3. Or, immediately after a change to "simple" style within MuseScore 3, but again, it goes away on save / reload. So, not a problem for 2.x scores that use a predefined tab style, and not a problem for MsueScore 3 scores except after a change in style, and not a problem for any score after save/reload. That's because the problem only happens if the beam is first created and then a change makes it go away.

Assuming my findings are correct, it's a more minor bug than it may have appeared at first, but nevertheless, here's a fix:

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

Reply

Fix version
3.0.3