Horizontal spacing: inconsistent spacing of same-valued notes
As far as I can tell, currently MuseScore uses a 'quasi-logarithmic' spacing for notes (chords) of different values: a minim is less than the double of a crochet and so on.
This is fine, as it allows to have in the same measure notes of very different value without having the longest extremely distant or the shortest extremely crowded.
However, this may led to strangely looking (and potentially misleading) spacing when notes of the same value are spaced differently to accommodate sub-divisions in other staves. For instance in:
- the two semibreves in cantus 3rd measure have a visibly different length, to accommodate the minims in other staves
- the second dotted minim in tenor last measure is very 'longer' than the first, to accommodate the dotted crochet and quavers of the cantus
- in the cantus last measure, the dotted crochet is quite 'longer' that the preceding minim and somewhat longer than the following minim
just to quote only the most visible cases.
In these cases, it could/would be very useful to have an alternative spacing algorithm which keeps the same horizontal horizontal space for all the same-valued notes in one measure.
This would be similar to the current "local relayout" flag used for beamed groups, but applying to all note values and not to beamed notes only.
I am aware that this would take more horizontal space than the current algorithm (often less measures would fit in a system than they do now). So, it is probably not something for a global switch, but something to apply locally (as "local relayout" does now).
At first sight, it could be a property of the measure, to turn on when needed (or when a simple manual adjustment would not be enough).
I expect this to have other aspects too, so discussion is welcome.
Thanks,
M.
| Attachment | Size |
|---|---|
| sample_varying_spacing_scaled.png | 13.55 KB |
Comments
With further thought, it seems to me this could be achieved in two different ways, not necessarily mutually exclusive:
1) By enforcing the same width for all same-valued notes of a measure. In the example above, 3rd measure, this would lead to increasing the width of the second semibreve in all staves, once the presence of the minims forced the first semibreve to be larger (of course, this should also work retrospectively if the 'wider' semibreve is the second).
This solution keeps the vertical alignment across staves, but takes more space.
2) By forfeiting the vertical alignment across staves and independently space each staff of a measure with the "quasi-logarithmic" spacing appropriate to it (this is what "local relayout" actually does). In the example above, last measure, this would lead to the moving the second dotted minim in the tenor part mid-way between the other two notes, regardless of what happens in the other parts.
This solution is more compact than 1) -- in practice, the global horizontal spacing would be the same as now --, but would disregard vertical alignment across staves.
I expect 1) could be more appropriate in some cases and 2) in other, so in the best of possible worlds both would be implemented (as described above or in other forms) and available as user choices. As resources are limited, some corner has to be cut, probably.
Again, discussion is welcome.
In reply to With further thought, it by Miwarre
I think both ideas have merit. Local relayout is currently limited to beamed notes, but it's a recurring request to extend it. Yet the idea of constant spacing for notes is attractive even without the local relayout.
In reply to I think both ideas have by Marc Sabatella
Probably each solution (as outlined above or in some other form, more or less equivalent) would suit some cases better than the other; for instance, in the above example, it is my (totally subjective) impression that the third measure would more benefit from 1) and the last measure more from 2), at least in terms of readability of the result.
To elaborate a little on the relation between them, they are not mutually exclusive in the sense that both could be implemented in the same software. But it would probably make little sense to apply both to the same measure, so from the user perspective, they might be mutually exclusive, in the sense that you could apply either one or the other.
About local relayout: Local relayout is currently applied to the beam itself, so extending it to non-beamed chords is likely to involve a re-design of the feature from scratch. I use local relayout quite a lot and I believe it fulfils appropriately and easily a real need. So, I hope it is here to stay.