Cross-staff beams getting jaggy and thicker from the side, an extra beam is also getting added

• Apr 15, 2019 - 18:36
Reported version
3.0
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Randomly
Status
active
Regression
No
Workaround
Yes
Project

Sometimes, beams go weird. They're not smooth than usually, they're like square and raise like stairs.


Comments

Status active needs info

In order to investigate, we would need you to attach the score you are having trouble with.

Also, check your "Draw anti-aliased" setting in Edit / Preferences / Canvas and see if changing it helps.

Something definitely seems wrong with your score or something about your settings / installation, but it's hard to investigate from just pictures. Can you please attach the actual score? Also, are you seeing this only with cross-staff beams? They are definitely laid out a bit differently, and that setting should help. Can you also try with 3.1 beta? Also, if you export as PDF, or SVG, or a high resolution PNG, do you see it there?

I have the same problem. When I edit something and the score is not yet saved, the beams look normal. However when I save it, it looks like: Saved.png
This only happens when the notes are spanned too long. When not, I don't know if the bug disappears or it just becomes less obvious so that I cannot see it through bare eyes.

Reported version 3.0 3.x-dev

I don't know but since my case happens in 3.1-beta, it should be updated...? Unless the post author and I are talking about different issues.

Reported version 3.0 3.x-dev

Ah, that explains why I don't hear them in 3.0.5, having 3.1 Beta installed too, along with the HQ soundfont
And yes, in 3.1 Beta I see it too

I don't see any problem loading this score into my current build, either. But I certainly believe the problem existed at one time and am by no means convinced it is fixed. I know that beam layout happens in several stages, and I could imagine something like the picture happening if things got out of sync somehow between those stages. Like, hmm, if in the middle of the layout, we realized we couldn't fit a measure onto the system we originally thought we could, so then we had to redraw it on the next system but it still had half-finished layout from before going on. That sort of thing, anyhow - that's not an actual analysis but more an example of the sort of thing that could potentially have been happening.

That said, I tried everything I could think of to force this problem to appear (looking at measure 25, clarinets, bassoons, and strings), and was not successful.

Frequency Once Few

I'm continuing to see this happen in the second 3.1-beta with scores created in the second 3.1-beta. To temporarily fix it a choose a start beam and reapply it and it looks better for a while, then at some point I edit something that seems unrelated and it becomes distorted again.

The jagged beams from the original report are different from the more distorted beams that appear in other reports. The jagged beams I do think are related to cross-staff notation, something about the fact they are laid out later than other elements, and as far as I know it's on on-screen rendering glitch only. As far as I know it won't affect print or export.

The other distortions are more seriously because even though they come and go, they can appear in print/export. However, I have now confirmed that all reported cases of this I have been able to reproduce are due to the same problem, which is #289933: Layout shift in measure at start of system. I have a pending PR for that. For the record, this can happen on the first measure of a system on a page >1 there are different key signatures between staves (eg, with transposing instruments), and one of the staves has a full measure rest at the start of the system.

In reply to by Jojo-Schmitz

This issue is not happening with me. Just a theory, but it could be a graphics card issue with OP since it is not happening to everyone. Graphic cards have anti-alias options. Wonder if updating graphic card drivers would do something.

Workaround No Yes

I will simply second those who have said they are experiencing this issue in 3.5. Usually, my workaround is to pick one of the notes in the problematic section, change it to a different note, and then back to the original one. This sometimes fixes the beam issues. I am not sure when the problem is showing up because it is the kind of thing that I notice later. I think it arises when the user is making certain changes, thus the inability of some to replicate it. It DOES show up in printed versions.

If anyone can come up with precise steps to reproduce this, we're happy to investigate further. But I cannot reproduce with the file attached in https://musescore.org/en/node/287770#comment-1020849.

Those who are still seeing it, in addition to precise steps to reproduce the problem, please tell us your OS, your monitor resolution, and your setting for anti-aliasing in Edit / Preferences / Canvas. Also whether you are using any OS settings, Qt environment variables, or MuseScore command line options to override MuseScore's scaling. And if you see this in a PDF export or print as well as on screen, please attach the PDF or a scan of the print as well. Since we current;y cannot reproduce this, we would need this information to provide the necessary clues to understand why it might be happening for you but not for us.

When I raise a cross-staff note by Up arrow, the bug happens more strong the higher I raise the notes.
The bug disappears when I save the score.

When I raise already glitched cross-staff note by Up arrow, the bug disappears from that measure, but it gets more strong in other measures.

I can indeed see the issue in the PDF. So, again, can you give precise step by step instructions to reproduce the problem? Which note specifically are you raising by a half step?

I can reproduce: (Windows 10 64-bit, 1920x1080)
1) Minimal file: minimal1.mscz
2) Duplicate these two notes in four measures (and 2 systems), and all notes G3 in cross staff notation: so: test1.mscz
3) Select the beam first beat fourth measure -> Arrow key Up, one time and more -> look at what happens in first system

Video_2020-09-04_181111.gif

Status needs info active

Aha! Now that I can reproduce, thank you very much! Hopefully that will enable us to figure out the cause and fix it.

I can see this behavior since the beginning of version 3, eg, this nightly on January 3, 2019: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4893, revision: c38df7a
Or this one in December 2018: cf1f5ce

Frequency Few Many
Severity S4 - Minor S3 - Major

Result displayed on the pdf is really bad, so Severity raised.

Frequency Few Many
Severity S4 - Minor S3 - Major
Status needs info active

We know how to reproduce the bug so it's active the programmers don't need any more information. A lot of people have reported it (Frequency many). Severity is major because there really isn't a way to work around this bug when you export it to a PDF.

The workaround is to make another edit, or export to PDF after loading but before making any other edits. At least that's how it seems right now. But the occurrence of this is random enough (even if reproducible with one particular score) that it's hard to say for sure.

I was able to reproduce the bug - Trapezoidal beams - on the latest nightly 3.5 version. I noticed something unusual. I had four measures of cross-beamed notes on two staffs. It ONLY seems to happen if I have more than one staff and only if I manipulated the beams on the second the fourth measures. If I manipulated the beams on the first and third measures, nothing happened. At least that is my experience.

"We know how to reproduce the bug so it's active the programmers don't need any more information. A lot of people have reported it (Frequency many). Severity is major because there really isn't a way to work around this bug when you export it to a PDF."
@mike320 Sometimes when I post comments, for some reason, they default to the previous settings.

The fault is still evident in 3.6.0 RC:
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.0.451380634, revision: 10dee08

Steps to reproduce: change any note in mm.5-6, on system 2 of example score
Expected result: no change in beaming on system 1
Actual result: all semiquaver beams on system 1 now have a tapering gap
Workaround: select affected measures, Ctrl+R

Thanks to @ashmoggs for providing the example score...

Title Cross-staff beams getting thicker from the side, from far away, looking jaggy Cross-staff beams getting jaggy and thicker from the side, an extra beam is also getting added

My explanation is that MuseScore doesn't clear the graphics in cross-staff beams, but instead keeps adding beams on top of each other, making it look jaggy.