Adjacent-note chords in different voices separated by a second not offset
Type
Functional
Frequency
Few
Severity
S3 - Major
Status
active
Regression
No
Workaround
No
Project
1. Open attached score (produced in 1.3).
Result: The lower of the multi-voice notes don't shift.
Notes:
The numbers represent the pages of 'Behind Bars' featuring these examples.
Page 49 states: "Arrange chords so that notes on the 'correct' side of each stem align vertically: … The only exception is when a tone or semitone separates the two parts. In this case, the lower part is displaced to the right (if the parts are vertically aligned, it is hard to tell which note belongs to which part):"
Using MuseScore 2.0 Nightly Build 2b0fda1 - Mac 10.7.5.
| Attachment | Size |
|---|---|
| Multi-voice notes separated by tone or semitone not shifted.mscz | 1.52 KB |
| Multi-voice notes separated by tone or semitone not shifted.png | 25.88 KB |
Comments
Thanks for the report. I'll look into how easy it is to detect these cases. Currently, the collision-avoidance code considers only the bottom note of the upstem chord and top note of the downstem.
Meanwhile, I'd love to see some independent corroboration of this bit of advice. It kind of comes off to me as a personal preference on Gould's part. Any other references on the subject anyone can point to, or examples in the literature? FWIW, it seems Finale applies the offset, Sibelius does not.
LilyPond doesn't apply the offset either.
I'm inclined so far to not apply the offset, and let users who wish to follow Gould's personal advice apply the offset themselves. This also works well with principle that says when in doubt, it's easier to manually offset two things that default to being aligned than it is to manually align things that default to offset (you'd need to know the exact amount of the offset and hope it remains constant from release to release).
But I'll leave this open in case new evidence comes in, also as a reminder of a possible feature to add in the future (an option to control the default).
It was originally discussed here .
These 2 also look odd to me...
![1.png]( "1.png")
![2.png]( "2.png")
Also
And
Second one above is arguably OK as is. First one certainly looks wrong but I can't figure out how to reproduce it.
1) note entry
2) C
3) Shift-D
4) Voice 2
5) B
6) Shift-C
7) Drag one the notes, it causes multiple of these weird configurations
See this one too:
![1.png]( "1.png")
This one might be clearer:
![1.png]( "1.png")
These configurations only happen when you have twice the same note in the same voice.
Got it. Probably worth filing those cases as a separate issue from this one.