Stem direction wrong for beamed chords (2.0 regression)
Steps to reproduce bug
1. Create a new score in 4/4, treble clef
2. Switch to note entry, 8th notes
3. Enter octave D's twice
Expected behavior: Eighth note stem directions should point up.
Actual behavior: Eighth note stem directions point down
Discussion: MuseScore gets the stem direction right for notes without a beam, but MuseScore 2.0 seems to ignore all but the top note of a chord for beamed notes.
MuseScore version: 6ba4ef6
(Operating System: Windows 7)
Comments
The typical rule for stem direction of beamed notes:
(To simplify the algorithm Finale apparently ignores the second rule and just assumes downstem. Sibelius appears to implement the second rule).
It would be great to have several visual tests for beam and unbeam directions.
Visual tests are small snippets that we can visually control for each commit (or at least from time to time). Any can come up with some tests? See the vtest folder for some examples and for example the notehead position test http://vtest.musescore.org/0ac248ae/vtest.html#noteheadposition-1
I fixed the current algo in 789ee8b274
It implements david's rule 1/ and default to downstem in case of equality.
Should be marked fixed then, I guess
I discussed rule 2. with David on IRC. Sib seems to have a different rule. The MPA guide "standard of music notation" suggests rule1. and down by default. Any other implementation ideas/recommendation? Gardner, Gould?
I have two relativley older sources I refer to. Gehrkens' "Music Notation and Terminology" suggests a majority-rules approach, period - not just to be used in cases where there is a tie in terms of which note furthest from middle line. I've seen this used in older manuscripts, but it definitely seems to be a minority opinion these days. Probably still some using it in case of a tie in terms of the furthest note from middle line. My other source is a short essay called "Writing Music Manuscript" that came with a book of manuscript paper I've had since the 70's. This one says stems go down in case of a tie. That is also the rule used by the publisher i have worked for.
I know I've also seen people espouse a rule where, in cases of a tie (and in particular, even for the case of a single middle line note) you make the stem consistent with that of the previous note.
I think bottom line is there is no answer so right that you'd be wrong to not do it that way. But predominant usage seems to be, down in case of a tie. So that's my vote.
I guess Gould has a rule similar to what Marc posted (with a fuzzy exception):
1. "The majority of stems go in the 'correct direction"
2. "The exception is when a minority of notes are much further from the middle stave-line than the majority. In this case it is better to have a majority of shorter stems in the 'wrong' direction, rather than many long stems" (p. 24).
Sorry, didn't mean to change the status
For anyone that is curious, the algorithm that Sibelius uses is to take a sort of average of all the notes sharing abeam.
1. Assign notes on the center line a value of zero (0)
2. Assign notes above the center line a positive value according to their distance from the center line
3. Assign notes below the center line a negative value according to their distance from the center line
4. Take the sum of the values. If the value is negative use upstem. If the value is zero or negative use downstem.
Then, what do we do? do we keep the current implementation.
1. the note furthest from the middle line determines the stem direction
2. if it's equal, down stem
Or do we implement another rule on top of it? or even the last algorithm David described (which would probably be a bit faster btw, we currently loop twice through the notes of a chord to get the top and bottom notes).
Doesn't really matter to me.
Automatically closed -- issue fixed for 2 weeks with no activity.