Horizontal spacing: up/down-stem alternating chords
As far as I can tell, currently MuseScore places note heads first and then attaches the stem on one or the other side according it is up or down.
In a sequence of same-valued notes, this leads to correct horizontal spacing if the stems are all on the same side and to acceptable spacing if switches up->down or down->up are occasional only:
If the note (or chord) sequence alternates up and down stems more frequently, geometrically correct spacing of note heads looks visually incorrect:
A better looking result (achieved by manually nudging every other note) could be:
The customary explanation is that, when stems are (almost) always in the same direction, the regularity of the bulky note heads is visually more important; while, when stem direction changes very often, irregularities in the 'vertical scansion' of the stems become more important.
Whether the reason, I believe some sort of automatic spacing of alternating stems would be quite useful and would lead to a better engraving result. Manual adjustment is possible, but it is rather labor-intensive and potentially not as precise.
I am sure there are other aspects to this area (vertical alignments with notes/chords in other staves, possible presence of 'obstructing' elements like accidentals or clef changes, and so on); so some discussion is in order, methink.
Thanks,
M.
Comments
Yes, this is a topic covered by Gould and I think also mentioned by Daniel Spreadbury in one of his blogs. One way Werner has mentioned doing is not using simpl left & right space values but to use bboxes or something simialr so that, for instance, a grace note on the top line can slide above an accidental on the bottom line. While the example here isn't exactlly the same, it strikes me as the sort of thing that is probably best tackled along with that other change.
In reply to Yes, this is a topic covered by Marc Sabatella
Well, obstruction and collision with other elements are factors which may make a general implementation quite complex.
But the simple (and more frequent) case has not to do with them: in the second example above, there is no collision whatsoever, and bboxes could hardly help. The point is recognizing the UpDnUp or DnUpDn stem pattern and displace the middle chord accordingly (to the right in the first case and to the left in the second).
An important part of the discussion could also be where to stop complicating the algorithm; for instance, it could make sense not to apply the correction in multi-voice measures.
In reply to Well, obstruction and by Miwarre
Right, like I said, your example isn't the same. But it's the same part of the code that would be affected - the code that calculates the space to allocate between chords. Since it's going to be rewritten anyhow, still seems to me like it might make sense to work on these together. The concepts are related, after all - somehow we are tweaking the calculation of the amount of space to leave.
In reply to Right, like I said, your by Marc Sabatella
Ok, I got it! Sorry, I didn't understand at first. M.