Beam should reach center line for notes beyond one ledger line
Steps to reproduce bug
1. Create new score for piano
2. Add beamed notes (such as sixteen notes) below the treble staff
Expected behavior: (Unless a stem is flipped) the stem should always touch the center line of a staff.
Actual behavior: Beamed notes ignore the rule and do not touch the center line.
Discussion: LilyPond makes all the stems literally touch the center line and has a horizontal beam for both groups of notes in the file attached. Sibelius and Finale allow a slight slope the distance of half a beam to hint at the direction of the notes. Both options are fine with me.
MuseScore version: 0.9.6.3 stable and r. 3661 nightly trunk
(Operating System: Windows 7)
| Attachment | Size |
|---|---|
| beams for notes on ledger lines.mscz | 26.78 KB |
Comments
Do we think this is related?
Think it's fixed in 2.0 nightly build (3953) - can someone confirm?
Looks like it is almost fixed. Here's another test case that still shows some problems.
The differences between Sibelius and LilyPond for the first set of semiquavers - what is supposed to be correct?
As before, either slope is fine with me. The important thing is that the beam extends at least to the center line.
Think it's now fixed in 2.0 nightly build (4079)?
Almost but the beam isn't quite touching the center line for the file attached to comment #3 above.
The behaviour has become worse - same result as 1.0.
Using MuseScore 2.0 Nightly Build (4303) - Mac 10.4.11.
This is work in progress.
Elaine Gould says in "Behind Bars": "When all the notes of a beam fall outside the first ledger line, the beam takes only a slight slope, regardless of pitches. Intervals of a second take a slope of 1/4 stave-space; all wider intervals take a slope of 1/2 stave-space.
I am still in the process of transforming all the various beam rules into code...
Not sure if it belongs here, but it is beam-related.
For notes with altered beam properties, they conflict with rests. Will this be addressed?
Also wondered about grace notes .
fixed in recent revision (r5546).
#10 is not handled yet.
Thanks Werner.
I think this should be kept open until #10 is fixed, unless it's another report?
#10 is unrelated to the original bug report. I would see it as a feature request. Currently MuseScore does not try to avoid collisions. This is something i see for version > 2.0.
Okay, we'll mark this one as fixed.
I have filed this: #16098: Rests between beamed notes don't relocate
Automatically closed -- issue fixed for 2 weeks with no activity.
This seems not to be fixed in 1.2 despite previous comments. Furthermore, when a beam is adjusted and then copied, it reverts, losing the adjustment.
Hi John P
This is fixed for the forthcoming 2.0 version (not 1.2) :).
No one ever said it was fixed for 1.2 - the 1.X branch has been closed to all but criticial bug fixes for quite a while. It is fixed for 2.0, which should hopefully come out later this year (and experimental nightly builds are already available, as suggested by the comments above).
Thanks. Sorry I missed that. I hope 2.0 will also enable adjustments of all kinds to be preserved when copied.
Currently it appears not to. You might check to see if there is an open issue for this (I know it has been discussed, but perhaps on the forums not the issue tracker), and open one if not.
In general, you'll want to download a nightly build for yourself (see Download link at right of this page) to try things out before submitting bug reports, so you can what the actual state of development is.
I don't know if the nightly build does this, but I think the intention is to preserve adjustments.
Thanks to you both. I tried the nightly build once and concluded it was not for amateurs like me, but I'll give it another shot. Perhaps I can at least tell if there is an open issue.
Definitely not ready for "real" use, amateur or not. Stick to 1.2 (or 1.3 when it comes out) fnormally. But any time you see a behavior that looks like a bug or that seems like it could be improved, you should at least give a shot on 2.0 before reporting it.