Stem spacing is odd when beaming between notes with alternate stem direction
When beaming between a note with the stem up (right side) and a note with the stem down (left side), the default distance between the stems doesn't look correct. I suspect there's some heuristic missing that should ensure the stems between two notes are never less than a certain distance apart (regardless of where the note heads might sit). Obviously you can adjust manually but the piece I'm currently typesetting has this in every bar and it's pretty painful to do hundreds of times!
Comments
BTW even without beaming it looks weird - if you just fill a staff with crotchets (1/4 notes) alternating between a D just below the staff and the G just above the staff the stems look awkwardly close. But if you use quavers (1/8 notes) and beam such that the beam sits in the middle of the staff it looks more obviously wrong. It seems like it's just trying to space the note heads evenly with no consideration of the stem direction.
Lilypond seems to do a better job here: http://lilybin.com/f2m6cf/2
or http://lilybin.com/f2m6cf/3
Vs musescore: https://ibb.co/98hxBKb or https://ibb.co/9wkZj37
In order for us to understand asssit, we'd need you to attach the score you are having trouble with,.
I can guess that maybe you are referring to a technique known as "optical spacing", where notes are deliberately spaced unequally in terms of the notehead so the stems look more even. I gather not everyone in the industry thinks this is a good idea, but certainly some do. MuseScore doesn't do this by default, maybe it will be an option someday.
In reply to In order for us to… by Marc Sabatella
Attached. The stem spacing here is definitely not like anything I've seen in professionally engraved/typeset scores. In principle, it's fine - quite readable and the even note-head spacing makes logical sense - but it just lacks "elegance" I guess. And at least in some real-life cases where there's a lot more going on, it's can cause you to double-take a bit when reading from it (which is how I noticed it in the first place, after printing it out and trying to play from a score).
In reply to Attached. The stem spacing… by Dylan Nicholson1
Indeed, that's a use case for optical spacing. Issues come up if there are other notes on other staves, as the adjustments required to make one staff look even will make corresponding notes obviously not even, or else, the notes won't be aligned. Which is probably is why this isn't really so universal. But still, it can be useful in cases like this.
In reply to Indeed, that's a use case… by Marc Sabatella
BTW I've attached an example of what I'd like the spacing to look like, but note I had to set the Format|Bar|Style minimum note distance to 0 and the note left margin to .5 to achieve this, which isn't ideal for the rest of the score.
Again, to be fair, the default spacing that musescore uses is quite usable, and makes sense, but it's just not what I'm used to seeing with traditionally engraved scores and jars a little.
In reply to BTW I've attached an example… by Dylan Nicholson1
...actually what the algorithm is for "optical" spacing I can't seem to figure out at all, because now when I add a second instrument that's playing the same rhythm (but without alternating stems) its spacing looks all wrong...I'm not even convinced that with proper optical spacing note heads with different stem directions but at the same time points are meant to line up exactly.
In reply to ...actually what the… by Dylan Nicholson1
Found this example from a traditionally engraved score where the spacing does indeed look odd in the part that doesn't have alternating beams:
But I also have another professional hand engraved score that doesn't have this problem, instead, as I suspected, the note heads themselves don't line up exactly between the parts (but it looks right - as I guess there is an optical illusion in effect). If I find a better example from a typeset score I'll post it.
In reply to ...actually what the… by Dylan Nicholson1
Yes, that's what I referred to above in pointing out a reason why this isn't universal and at least part of why an automatic facility for it was never implemented. Just defining what the expected results should be is tricky!