Unnecessary beams over rests
Musescore 2.02 and the nightly builds will create thick horizontal lines over rests which are unneccessary beams to nowhere.
Creating a note followed by several rests and then selecting a middle beam over one of the following rests will create this unnecessary beam.
Attached file was created with nightly build bec7074 under Windows 10
| Attachment | Size |
|---|---|
| unnecessary_beam_over_rest.mscz | 3.9 KB |
Comments
This is by design and sometimes wanted. If you don't want it, just don't do it
See also https://musescore.org/en/node/11370
It is debatable though, whether rests should a) default to Beam::Mod::AUTO and b) that in turn should be Beam::Mode::NONE for rests.
And whether anything but Beam::Mode::AUTO or Beam::Mode::NONE for a rests should require a note to follow.
See ...libmscore/chordrest.cpp, line 180ff
The beam is necessary in your example because there's a note that follows the first note. But in my example, nothing follows the note except for rests. So here the beam is unnecessary and confusing.
It is still by design and as such not a bug. Also this is garbage in, garbage out, so if you change the beaming defaults for rests so something non sensible you get what you asked for.
Musescore automatically beams over rests, so I don't see how this is garbage in. From what I can see, the way Musescore handles beams over rests (automatically putting them in) seems to bother more people than it helps. There shouldn't be any beams over rests, but this has already been addressed in other forum topics.
If you enter a rest, it's beaming gets set to NONE, and with that there won't be a beam across it. If you change away from that default, without having 8th or shorter notes before and after that rest and have their beaming set properly, this is a non-sensible setting, and this is what I mean by garbage in / garbage out
Maybe we can discuss this a little bit more. How did you create this file? You really selected a middle beam over one of the following rests? Why?
One situation I can imagine is Ctrl+A to select all, or select a (series of) measure(s), then a double+click on Auto or some other entry in the beam palette.
Here is what OP's .mscz looks like:
But I disagree with the OP. I actually encounter beams over rest quite a bit, and can be useful. Especially when dealing with music that has lots of odd time signatures, in which case using beams over all rests and beats that correspond to the subdivision of the odd time can dramatically help out in readability and not falling apart. E.g. if have a 3+2+2 subdivision in 7/8 time, then reading with beams over rests like:
is much easier than trying to follow this:
Also even in 4/4 time, it can help out when having lots of syncopation, just to know where exactly the beat begins.
There is actually a feature request that I would like to add, and that is the ability to add stems to beamed rests. For example the OP would look like:
if user explicitly added stems to the rests (of course would not be default behavior).
@ericfontaine, these are called stemlets (see for example https://musescore.org/en/node/69936). Please open a feature request for this.
Thanks lasonic, I made issue: #100111: stemlet (stems over rests)
Back to the OP,
I would suggest issue be changed into a feature request "remove unnecessary beams over rests". I think maybe implementing this as a cleanup plugin would be more appropriate than inserting into regular code base. That way user can temporarily have beams over rests (as is currently able to do with beam properties), if desired.EDIT: I just realized that it is much simpler to just right-click any rest, select all elements of same type, and then double click the beam-none option.I always forget about the ability to select elements of the same type in Musescore. Thanks for the workaround.
Regarding the original .MSCZ, I encountered this problem while importing a Music XML file that was saved by Sibelius 7. Musescore made all the eighth notes into notes with no beams (i.e. none were joined) so I orignially tried to select everything with Ctrl+A and choose the "middle beam" option. Then after selecting the first note in the measure and choosing "no beam" I noticed the lingering beam over the rests. I thought the beam would just go away on its own.
But again, using ericfontainejazz's method of selecting elements of the same type and avoiding the rests would have avoided this beaming issue.
Select All, Layout > Reset Beam Mode is the simplest way to go, really.
BTW, I have been under the impression for a long time that "Reset Beam Mode" was the same as "Auto" in the Beam Properties palette. But the latter does something different in this case. What is the difference, and why is one in the menus and the other in the palettes?
Regarding the original .MSCZ, could you post the MusicXML file? Also could you post a screenshot of the Sibeliusscores as viewed in Sibelius7? I'm wondering if that is how the stems were notated in Sibelius, or if possibly there was an error in Sibelius->MusicXML export, or if there is an error in MusicXML->MuseScore import.
Maybe does "reset beam mode" return the beams to whatever scheme is defined in the Time Signature properties?
Here are all the files as requested. The Sibelius file was created with Sibelius 2 but opened just fine with Sibelius 7. I no longer have that software installed on my computer but the PDF file is what the score would look like when opened in Sibelius - both the PDF and the MusicXML files were generated by Sibelius 7.
Importing the MusicXML file into Musescore, selecting everything with Ctrl+A and choosing auto beams is what brings the problem regarding the beams over the rests as per my post above. When trying to get rid of the extra beam by choosing "no beam" on the first note of the measure I would get a lingering beam over the rests.
>> "selecting everything with Ctrl+A and choosing auto beams is what brings the problem"
Well I actually consider what musescore does to be expected behavior, "by design". If you wanted to just beam the notes, then you would right click a note, select all similar elements, then double click beam auto. Or do as Zack says and use "reset beam mode".
And it seems that the MusicXML file doesn't seem to contain the beam information. The reason I say that is because if I import that MusicXML into Finale Notepad 2012, then I don't see any beams:
So probably when you exported from Sibelius 2 to MusicXML, the beams did not get exported into the XML. Maybe Sibelius 2 didn't have that feature implemented in MusicXML export (or maybe MusicXML didn't have that defined)??? But I don't know anything about those implementations.
I say close this issue, because everything on MuseScore's end seems to be working as expected, I believe.
EDIT: visually inspecting the MusicXML file in text editor, and searching for beam, I only see two occureces:
and
But nothing else, such as start beam and end beam info.
The only issue I could imagine is a feature request to have MuseScore's MusicXML import apply a "reset beam mode" at the end of import, if there are no beams defined in the MusicXML.
Looks pretty much like a duplicate of #52151: "Auto" beam setting for *Rests* should not beam (if no stemlets)
Well, I would argue that they are not duplicates. I think this issue 99761 should be marked "as designed" since MuseScore is behaving exactly as the user is commanding it to:
"Creating a note followed by several rests and then selecting a middle beam over one of the following rests will create this unnecessary beam."
Forcing mscore to beam rests will be important if the stemlets feature I requested gets implemented.
Now your issue I think is more subtle. Your issue (in my view) is not the fact that rests get beams when they are specifically told to beam, but rather that you think the default behavior for rests when their beams are set to *AUTO* should be that rests don't beam. I would agree that rests should not beam when set to auto. But I would consider your issue to be a "feature request". :)
Well, by design or duplicate doesn't really make that much of a difference, the end result is the same, the issue will not be work on.