Disappearing beam while editing slur node
Doesn't make much sense, but I'm experiencing the disappearance of a beam on the previous measure while editing a slur node. It seems to re-appear only when the measure in which it is contained is edited, and not any other measure even in the same system, which is most definitely a problem. Won't be sharing the exact score, but maybe it can be reproduced in a basic score. For now, here is a screencast showing what's happening. It caught my eye mainly because of the finger-text position shifting in the process, causing a weird layout change also that can be slightly offputting:
Version 3.4.2
Update: Further specifications: the beam is actually connected [set as middle position] to a previous measure's beamed note, and that measure breaks automatically into a new system. This seems to be the main area of the problem. That is, the previous measure has a note that has beams set up to cross-measure beam. If I take that off and make the beam connect as only a single beam, then this problem doesn't occur. So the issue is some how in the cross-measure beaming in addition with a new system between them, and then what was demonstrated in the screen-capture occurs.
Comments
There are other knowns glitches involving cross-measures beams that appear and disappear on edits, so probably related.
Yes. I've also run across something similar where a beam disappeared when it wasn't cross-measured, so I'm not sure if it's 100% cross-measuring, but it was probably related in that maybe a previously cross-measured beam and its problems some how affected another beam later in that measure.
I tried to reproduce this issue but I failed. Is it possible to share an example?
In reply to I tried to reproduce this… by njvdberg
Sure. Since original post, one crucial piece of information about this bug has been made known (might be the reason why you failed to reproduce the problem):
1) There must be no manual line break between said systems.
If there is a manual line break, the problem doesn't seem to manifest. This especially happens when trying to recreate the issue, as it's most natural to attempt cross-system + measure beams with a manual line break.
So either use bogus notes or stretch, or with the following attachment is a bunch of blank measures first. With this file, attempt the activity as shown in the screencast. I.e,. select the second measure of the second system, and move a note or a a slur and watch the first note's flag of the first measure of that system "disappear".
In reply to Sure. Since original post,… by worldwideweary
Thanks, this is really a very simple example but it indeed shows the issue. I think I found where is goes wrong but need some more tests to be conclusive.
There is a simple way to correct the beam, just change something on the previous system and change it back (e.g. shift a rest up and down), this will restore the beam.
When a system break is between two measures of a cross measure beam, the beaming algorithm nicely replaces the the cross measure beam by hooks. This system break can be intentional by placing a
SystemBreakelement or the result of the auto-placer but both cases are handled correctly by the beaming algorithm and the cross measure beam is replaced by hooks.The problems starts when something is edited on a system starting with the second measure of a cross measure beam. The edit will cause a re-layout, starting at the beginning of the system where something was edited.
As long the auto-placer knows the first note it sees is part of a cross measure beam it will know the hook is there for a reason. The root cause of the issue was the auto-placer didn't take the situation onto account when the system break was the result of the auto-placer itself, this information was lacking during the partial re-layout triggered by the edit.
PR is on its way but during the tests I saw some strange artifacts and want to know whether these are introduced by this PR or not.
https://github.com/musescore/MuseScore/pull/5918
The pull request was merged. This issue was not automatically closed due to a "#" missing in the commit message.
Automatically closed -- issue fixed for 2 weeks with no activity.