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:
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.
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.
I get the exact results in the 3.1-beta. I zoomed in to see the viola, cello and bass. I changed the G in the viola up then down and saved. The beams then did what is in the picture at https://musescore.org/en/node/287770#comment-915280
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.
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.
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.
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.
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
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
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...
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.
Comments
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.
Picture:
Which version are you using? I don't see this in 3.0.5, but I saw it in earlier 3.0.x versions.
In reply to Picture: by BetaBleeds
Did you try the setting I mentioned?
In reply to Which version are you using?… by mike320
3.0.5
In reply to Did you try the setting I… by Marc Sabatella
I tried. Did not help.
It happens when I insert notes. What more notes I insert, the bigger the bug gets. 16th-beams get increasingly thicker.
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?
Here. But the bug doesn't appear anymore.
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]( "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.
In reply to Something definitely seems… by Marc Sabatella
@Marc Sabatella, my case isn't cross-staff, see the comment above
Score needed...
In reply to Score needed... by Jojo-Schmitz
Here. Look for the Gnome part.
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.
I don't see anything weird. I just don't hear certain instruments (weird enough)
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
In reply to I don't see anything weird… by Jojo-Schmitz
Don't hear certain instruments?! This doesn't happen for me.
But the beam problem is still present on my computer.
In reply to (No subject) by Jojo-Schmitz
It looks normal when I download and open it and do nothing. But if I press Ctrl+S (with or without some editing) the beam turns weird.
EDIT: OK, so the problem should be with 3.1-beta...
Looks good though in the latest development build, so seems fixed there.
I guess it is a different issue that the OP's though
The OPs score is from 3.0.5, so surely a different issue
In reply to Looks good though in the… by Jojo-Schmitz
Yeah I believe so. (What can possibly cause this bug though?)
Does it matter, when it is fixed meanwhile?
In reply to Does it matter, when it is… by Jojo-Schmitz
Yeah, doesn't matter. Just curious.
understood ;-)
Strange, now I don't see it in 3.1. beta anymore.
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.
I get the exact results in the 3.1-beta. I zoomed in to see the viola, cello and bass. I changed the G in the viola up then down and saved. The beams then did what is in the picture at https://musescore.org/en/node/287770#comment-915280
I can't reproduce in current master, so maybe something really was fixed here.
Those jagged beams came up again in https://musescore.org/en/node/288568
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.
(edited) Need more investigation.
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.
Came up again in #297171: Weird jagged beams are still in 3.3.2.
Still in 3.4.2. Anti-aliasing on.
Sample score needed. And try whether it looks OK in 3.5 Beta
In reply to I have the same problem… by Howard-C
Still in 3.5. Anti-aliasing on.
Not for me:
![Nimetoen.png]( "Nimetoen.png")
In reply to (No subject) 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.
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.
Windows 10 64-bit, 1920x1080, Intel HD Graphics 4600.
It also happens in a PDF:
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
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
In reply to I can see this since the… by cadiz1
And pdf: test1.pdf
Also in March 1, 2018 (cd7d435), so very-very former issue, and apparently concubstantial to the beginning of implementation of version 3.
Result displayed on the pdf is really bad, so Severity raised.
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.
In reply to (No subject) by BetaBleeds
(edited - crossed messages)
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...
In reply to The fault is still evident… by DanielR
Here's an image.
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.
Like in here: