Beam should reach center line for notes beyond one ledger line

• Nov 2, 2010 - 02:33
Type
Functional
Severity
S4 - Minor
Status
closed
Project

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

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...

#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.

Status (old) closed active

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.

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).

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.

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.