Bad Spacing with Tuplets in 2.0 Beta

I think you are mistaken about "rules" of music engraving - unequal spacing happes quite often, actually. Both because of accidentals or grace notes and also because of the contents of other voices/staves. It's easy to find examples of all of these cases in the published literature, and Elaine Gould very specifically address the topic on pages 41 and 490 of "Behind Bars" (although does not go into much detail). In the other hand, it does make sense to even out the spacing if it can be done without adding a lot of extra space - just by rearranging notes and possibly allowing some overlap between voices. So again, that's what the "Local Relayout" option is for - so the human engraver looking at the score can decide on a case by case basis whether any particular passage is best rendered with or without that option.

Unfortunately, Finale did not get the spacing right for the sextuplets - especially the second group. I would also suggest that even the first two groups of sixteenth notes in the Finale example could benefit from some manual adjustment.

I'd still say that talking about "right" and "wrong" when it comes to layout is not always appropriate - engraving is as much an art as a science, with many subjective decisions to make along the way.

MuseScore's default layout uses a very straightforward and quite "correct" (for most situations) rule: notes played at different time must not overlap. This is right for most situations, and that is what MuseScore does.

There are some special situations where in the personal opinion of the engraver it might be wise to make an exception and allow overlap in order to even out spacing if he or she judges the result will be more pleasing, easier to read, and/or take less room. It's a judgement call. MuseScore can automate *some* of these cases via Local Relayout, but the algorithm won't handle all cases equally well, because the expected result is a prsonal decision that depends on many factors.

In the cases where the algorithm used by "Local Relayout" does not yield the desired results, some form of manual override will be necessary to get precisely the judge one subjectively has decided one wants. This appears to be one of those cases. Luckily, MuseScore makes it very easy to move the notes around however you like - either double click and use arrows, or use the Inspector for more precision and predictability.

What is happening in this case is that MuseScore is spacing the notes *within* each sixteenth note beam, but doesn't realize you also want the notes equally spaced *between* the groups. Change it a group of eight sixteenths and you get the you results you wanted - with more even spacing in the tuplet than Finale as well. So *in this case* at least, it appears if the algorithm treated adjacent beam groups with Local Relayout set as if they were a single group, you'd get what you wanted. But I'd bet there would be plenty of other situations where this would *not* be what you wanted. There is no way way one single algorithm is going to yield exactly the results you desire in all cases, unless maybe if you wrote the algorithm yourself to meet your own personal preferences - but then it would fail to meet someone else's.

Maybe it is true that considering adjacent groups together would be better in more situations - that I can't really say. Feel free to file an issue to the tracker, preferably accompanied by enough real-world examples from major publishers to help establish what the preferred behavior might actually be.

In any case, it's a pretty special case we are talking about here, and the manual positioning should allow you to get whatever result you personally prefer in any given situation.

Sibelius, BTW, produces something rather like MuseScore's default.