Centered measure numbers slip under articulation
See the three attached scores and the PDF which contains prints of all three.
... and yes, I need/want centered measure numbers - not on all measures, but on every second: This is customary for wind band scores, and I use it for some choral scores, as it removes awkward measure counting.
Playing around with the Inspector on the out-of-place articulations has weird results (but I did not follow a precise script, so this is more like "hearsay"): The inspector shows 0 values for both the low and the high articulations; increasing and decreasing makes them jump around, with - it appears to me - another "0 place" that is somewhat lower than the "default placed" articulations. Saving and re-opening keeps some of these changes, but not others ...
H.M.
| Attachment | Size |
|---|---|
| ArticulationsVsMeasureNumbers.pdf | 49.47 KB |
| ArticulationsVsLargeHighMeasureNumbers.mscz | 5.26 KB |
| ArticulationsVsLargeMeasureNumbers.mscz | 5.27 KB |
| ArticulationsVsMeasureNumbers.mscz | 4.96 KB |
Comments
Currently (including in the MuseScore 4 alpha), measure numbers take priority and other elements avoid them. This is desirable for most things, but probably not articulations indeed.
Meanwhile, simplest workaround would probably be, disable autoplace for the measure number in question.
In reply to Currently (including in the… by Marc Sabatella
I risk arguing that there is more to this.
First, my third example "LargeHigh" shows that even if you move the measure numbers "into the sky", with lots of empty space below them, the articulations still are put above them - this is not simple avoidance, but a sort of panic.
Second, when I look into the inspector, I see that the Y numbers there do not at all match what I see; and, especially, when I change them, the articulations jump up and down - I have seen some of them at three different heights when the number in the inspector was zero in all three cases. So I am quite sure that there is some design bug in there that should be fixed - either it is not always clear what the "zero height" is against which a position is measured; or some events do not pass through the object model (on loading, on changing Y, on adding or removing elements) quickly and harshly enough to make sure the layout settles at a stable place; or both. But this is only the hateful gut feeling of a software architect seeing what's happening (and finding such problems after only 2 days of using the software ...).
For the workaround, yes, no problem with it - and, granted, the chance that such things happen in real scores is definitely small.
H.M.
In reply to I risk arguing that there is… by hmmueller
The collision avoidance is a first-come, first-served algorithm. Which element type is defined to go closest to the staff, will win even if you move it further away. Other elements will move further as well, unless you disable autoplace for one or the other. Normally, it's the element you are moving further away for which it makes sense to disable it, because then the other elements that can now move in close will still benefit from autoplace.
And yes, when autoplace is involved, the offsets shown in the Inspector can be deceptive, because it isn't showing the actual position but rather the position that is set, and autoplace can still be displacing things from there. Articulations are special in that their default position varies based on a number of conditions, so I wouldn't be paying much attention to the numbers there; they will indeed be very difficult to predict unless you know all the rules for articulation layout.
But absent autoplace, most elements that are placed above the staff have a zero position coinciding with the top line of the staff. That you can take to the bank. But an element can have a zero offset and still be positioned further above the staff, if autoplace demands. The Inspector deliberately does not alter the position as set by the style or by you just because autoplace moves it. This would actually make it harder to achieve consistent and predictable results when editing.
In reply to The collision avoidance is a… by Marc Sabatella
Thanks a lot for the detailed explanation (which shows that my assumptions were mostly wrong; but by writing them down, I got a helpful answer from you). I now understand "it's a feature, not a bug".
H.M.
In reply to Thanks a lot for the… by hmmueller
Can it be both? :-). Definitely the overall way things work is a feature. But there can also be odd quirks along the way. These mostly have to do with the way the "minimum distance" fits into all this. That parameter controls how much space autoplace enforces as a buffer around an element when doing the collision avoidance. If you deliberate move elements closer to the staff than this buffer would allow - possibly to the point of actually overlapping other elements - then MuseScore automatically decreases the minimum distance for the element to compensate and to allow the relative positions to be maintained through subsequent edits. But this change won't be shown in the Inspector right away, leading to some hard to predict outcomes in some cases. And some other slightly gotchas like that. But overall, the system works well.