beam shifted from one bar to another
S5 - Suggestion
After downloading version 2.03 I opened a .mscz file created with version 1.3. The beam which should appear in bar 14 to join the quaver-semiquaver rest-semiquaver now appears superimposed at the beginning of bar 12 and cannot be manipulated. When the file was created with version 1.3 this problem did not exist .
|7.3 - molto adagio - getransponeerd.mscz||4.18 KB|
Try Ctrl+A, Ctrl-R
Thanks for the speedy reply.
Ctrl-A + Ctrl-R solves the problem partially: The spurious beam is removed from bar 12, but remains missing in bar 14. See attachment.
Compliments and greetings from fransejur
The assigned field is for the developer that fixes the bug, not the reporter...
Are you sure that there should be a beam?
Can you share the 1.3 score too?
See #16278: Beaming notes over barlines and line breaks. The problem is that the first note in bar 14 has been set to "beam middle" - that is, you have asked MuseScore to connect it to the last note of the *previous* bar. Beaming across barlines is supported in MuseScore, but it doesn't work if the two bars are on different systems. It didn't work in 1.3, nor does it work in 2.0.3 - it just fails in different ways. Probably the way in which it failed in 1.3 wasn't as visually noticeable - or maybe these two measures were on the same system in 1.3 so it didn't come up, but would have had you added a line break between the two measures. And for all I know, you might not have actually even intended the beam to be across the barline, so if 1.3 was messing up by simply not displaying the beam at all instead of displaying it on the wrong measure, you wouldn't have noticed this was wrong.
Anyhow, the workaround is simple - resrt the first note of 14 to "Auto" using Beam properties.
I am not sure I understand what you suggest I may have done in the original set up. I do not remember having done anything unusually complex when creating the score first time in 1.3; please find the result of that attached as it was printed, then.
Meanwhile, I managed to correct the score in 2.0.3 without difficulty.
Lastly, I want to express my admiration for this marvelous program and, notably, for making it available free!! Many thanks for that.
Even though you apparently did not intend to, you actually had asked MuseScore to connect the first note of bar 14 to the last note of bar 13. You can see this by simply clicking the first note of 14 and then looking at the Beam Properties palette. You'll see the icon for "Beam middle" rather than the "Auto" icon is selected - this shows you had previously asked that note to be connected to the previous note. Maybe you didn't mean to do it - you were probably just trying to get the *rest* to be under the beam, and accidentally applied the "Beam middle" to the first *note* as well, thus asking MuseScore to connect that note to the last note of the previous measure.
So, without intending to, you asked for the first note of 14 to be connected to the last note of 13. But 1.3 had a bug where that would not work if the previous note was on a different line. So as your PDF shows, no such beam appears - meaning 1.3 didn't do what you actually *asked* it to, but the bug caused it to happen to do what you actually *wanted*, so you weren't even aware there was a problem with your score or with MuseScore.
2.0.3 "partially" fixes the bug, so that now it at least *tries* to connect that note to the previous note. But as you can see, it gets it wrong, putting the beam way up on the line above rather than in bar 14 where it belongs.
So by trying to do what you had been asking for all along, 2.0.3 is showing you the error in your score that 1.3 was hiding from you. But by nonetheless doing it *wrong*, you ended up with neither what you asked for *nor* what you actually wanted.
Anyhow, bottom line: correct the error in your score (set that first note back to "Auto") and all is well.
Thank you very much for your clarifications. It is now crystal-clear to me what has happened: I made a mistake, which remained "hidden" in 1.3, but showed up as a seeming error in 2.0.3. I checked as you indicated and found you to be 100% correct. Thanks for the help.
Greetings and best wishes from Juri Roest