Some score issues …
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.5868, revision: 38f81d1
Open the attached file (2.x) and take the reset. Some observations:
- If you move a dynamic to the left (say), so that it "tucks in" to the top system, notice that it is virtually touching the note-stem. Is this too close or by design?
- Select the voice 1 rest in M9 and move it up and down. This causes a visible relaying out of the system for no apparent reason.
- In M15, observe the large space above the hairpin. Is there any way to reduce this without turning AP off?
- M20 (and others). The custom dashed line has been set to the default style, but could it preserve the "wide dashed" style from 2.x?
| Attachment | Size |
|---|---|
| score_issues.mscz | 46.53 KB |
Comments
1) Can you be more specific about which dynamic you are moving, and how you are moving it? I tried clicking the "p" on the first note and using the left arrow to nudge it. After 17 clicks (1.70 sp), it tucked in, and does not touch the stem, nor did it at any time along the way. I tried the same with the "p" at the beginning of the second system, and it's closer to touching but still not.
2) The vertical position of the rest influences the amount of space needed to avoid collision with the preceding or following note. These space calculations add up to determine the "default" width of the measure, before stretch is applied to fill out the system. That slight difference then gets magnified by the stretch algorithm. It's not necessarily but just kind of how things are, lots of other similar examples to be found. For example, try adding a natural to the last note of the same measure, plenty of room for it, but it has the same subtle shift effect. Very doubtful there would be a way to change this without some pretty fundamental changes to how we do layout.
3) Not currently. The minimum distance between a hairpin and whatever is above is currently hard-coded as 0.7sp. In this particular case, it's a little worse because we're actually calculating from the "bounding box" of the hairpin (draw a rectangle around the hairpin), so we're losing an extra fraction of an sp between the tip of hairpin at the left and where the top of that box is - it's 0.7 sp from the top of the box to the beam, not from the tip of the hairpin. The fact that both the beam and the hairpin slant the same way means it's a missed opportunity to take advantage of a tighter calculation. If/when my PR https://github.com/musescore/MuseScore/pull/4730 gets merged, there will be a style setting to allow a different minimum distance than 0.7 sp, but then you might find it close in other cases. Eventually we should probably do better than use the bounding box for hairpins, but instead really break the shape down into a bunch of tiny boxes like we do for slurs and beams. Long answer to short question :-)
4) I'm not sure how "wide dashed" actually worked in 2.3.2, but I can certainly see that in this example at least it had larger gaps. Not sure if those gaps were always the same or if it depended on something. If was always the same, it should be simple enough to set this better on import. Looks like a gap width of around 18 (no idea what the units are) gets close. Feel free to submit an issue for this, but maybe do some more experimenting first to see if it really is always the same.
In reply to 1) Can you be more specific… by Marc Sabatella
Re: 1. See any of the dynamics in M 1, 16, 23, 24, 36, 37. For example, M1. Use the left arrow to nudge the P until it just tucks in to the top staff. There is virtually no separation at all from the stem of the note to the right or the arpeggio symbol.
And you can continue to nudge the dynamic upwards a bit to overlap the tip of the arpeggio. The AP min. distance (0.5sp) doesn't seem to be working in this case.
In reply to Re: 1. use the left-arrow to… by geetar
I see separaton in your image. The min distance setting controls how far an element will be moved above/below the skyline if there is a collision. It does not control the detection of the collision in the first place. Perhaps it should but that is not currently how it is designed. The bottom line is that this should be thought of as a vertical minimum.
In reply to Re: 1. use the left-arrow to… by geetar
(I can only say by looking at the picture you added:) Although it may seem that it is a little touching due to the applied anti-alias filter (shadow factor), there is a gap between them.
In M1, when the dynamic is under the arpeggio symbol, AP min. distance settings below 0.9sp have no effect. But when the dynamic is under the note stem, AP min. distance is effective down to 0sp.
In reply to After the dynamic in M1 has… by geetar
It appears that way indeed, but the problem is actually different (and worse) - the arpeggio is not being accounted for properly at all. Try moving it further from the chord, and adding a lower note so the apreggio goes lower, you'll see autoplace will gladly allow the dynamic to collide with it. Apparently ont the very top portion of the arpeggio gets counted. So it's enforcing the 0.5 sp min distance only against that top portion fo the arpeggio. That's a bug for sure, definitely worth submitting: "shape of arpeggio only includes top portion".