Beam customizations don't scale when staff size changed.
OS: macOS 10.15, Arch.: x86_64, MuseScore version (64-bit): 3.4.0.24689, revision: 684f74e
In lengthy a score where I carefully adjusted many beams, via their handles, for the effect used in my published source, I found that they were not scaled when I subsequently chose a smaller basic staff size, resulting in chaos. I hope this is clear enough without images/scores (if not, I'll provide). I had to go back to my original staff size; at least that worked by virtue of the same!
Comments
Hey. Although I personally can't help with this issue as I understand it, to clarify, when you say smaller basic staff size, do you mean the [scale %] property of the particular staff, or the entire page scaling, or something else?
In reply to Although I personally can't… by worldwideweary
I mean "staff space (sp) mm" on Format > Page Settings, which i changed from 1.7 to 1.1.
In reply to I mean "staff space (sp) mm"… by [DELETED] 1831606
I can attest that doing this also doesn't scale perfectly in Linux, but it isn't super crazy.
![1.png]( "1.png")
As a simple example, Here's 1.764:
and 1.164:
![2.png]( "2.png")
They don't align perfectly with the note there, but it's not too bad at least for this [random] quick test instance. It would seem that the right-side of the beam should be, in this little instance, at the same level as that low-note to its left, but instead it's a little above it.
In reply to I can attest that this also… by worldwideweary
Try my latest score (BWV 35.1). The Bach-style "stems on both sides" beams, e.g., m.30 (user #ing), bass parts, go completely crazy at 1.1
In reply to Try my latest score (BWV 35… by [DELETED] 1831606
Yeah, that's where it really shows to be a bad current implementation. Maybe the beam offsets can somehow be given more of a relativism like with staff texts when the "follow staff size" property is enabled or something, or like with everything else. Heck it's probably an easy fix to someone who knows the code. Sounds like this should be in the issue tracker.
In reply to Yeah, that's where it really… by worldwideweary
I'll craft an appropriate entry.
In reply to I'll craft an appropriate… by [DELETED] 1831606
Until I do that, here are the two relevant images:
![zigzagprob1764.png]( "zigzagprob1764.png")
![zigzagprob1164.png]( "zigzagprob1164.png")
before
after
In reply to Until I do that, here are… by [DELETED] 1831606
Sorry I missed this when I fixed a bunch of similar issues for 3.1. Unfortunately, I suspect fixing it will mean breaking existing scores that rely manual adjustments of beams on small staves - either a given adjustment will mean what it currently means or what it should mean, no way to make it mean one thing for some scores and another for others. Unless we're getting lucky and the problem occurs during the act of making the staff small rather than in the internal representation. Unfortunately the code dealing with beams is about the most complex & hard to work with sections of the entire codebase.
In reply to Sorry I missed this when I… by Marc Sabatella
May I be so crass as to suggest that when staff-scaling of existing staves is changed, it should go through them and find things that need to be adjusted? It seems crazy that i can go through them all by hand, but the program can't. I don't see an issue of extant scores, unless someone expects to change staff sizes and have it give two different results for such beams. The vertical places relative to the staff where the beam starts and ends should not change.
In reply to May I be so crass as to… by [DELETED] 1831606
Of course things should work right when scaling changes, I'm just saying apparently this fell through the cracks. But as for the compatibility issue, there are two ways the beam / stem offset information could possibly be implemented currently. Either we keep the actual offsets the same but apply the scaling during layout/drawing, or the actual offsets might be scaled at the moment you scale the staves. If it's currently handled the latter way, then we're good - anyhow who had already customized their offsets to work with the scaled staff is safe, because the layout/drawing code wouldn't be affected by a fix. But if it's currently handled the former way - as most things in MuseScore are - then it's a problem, because now we're talking about changing how the scaling is applied during layout/drawing, and this will affect existing scores.
As an example of the difference, consider font sizes. These are handled the former way, A 12 point font continues to say it is a 12-point font even when the staff is scaled down - the scaling is applied during layout/drawing, not at the moment the staff is scaled down. So we still record font size as 12 point internally and still write it to the file that way. But in MuseScore 1 (!), it wasn't that way - the font size would actually change and be recorded in the file that way.
In reply to Of course things should work… by Marc Sabatella
As you say, someone who knows that area of the code should speak to it. Not being able to change the staff spacing unit without destroying beams is real problem. I'd like to reduce my 64-page score to the 18 pages it ought to be (it's 17 in the Bachgesellschaft, 2 sys/page, but those are larger pages, too).
I did a few experiments and realized:
After changing page scaling, if the algorithm didn't touch at all the x/y offsets of beams, the results would substantially be better and almost exactly right. Maybe I missed a few situations, but for the most part, the results were really decent. The point is, I think one way to fix the main problem would be to keep the x/y offset of beams and not "scale" them while undergoing page scaling changes.
To illustrate, here's a scenario (notwithstanding 'unorthodox beams'):
![1-(0.964).png]( "1-(0.964).png")
This is at Scaling: Staff Space: 0.954:
After making this, if I set Scaling: Staff Space to 2.364:
![2-(2.364).png]( "2-(2.364).png")
Noting the difference of placements, I now go back to the original X/Y offsets and put them into the results in this 2.364 spacing and get:
The results are very similar to the original, nevertheless a little bit off with the first beam's right handle. Even though it isn't perfect, merely keeping the original values would be much better than (at least based on this example) doing whatever MS is currently doing with those values and "scaling" them, since the values are already slightly relative to the staff and don't need much changes.
It seems the only changes that might be useful are the slight spacing size change that occurs between staff lines after scaling. If that could be taken into account, and only that into account while scaling, it would probably get a more perfect "copy" of original beam layout.
In this sense, a basic "keep x/y offsets of beams while page scaling" should be really easy to implement code-wise if this were proven in more experiments to be generically appropriate behavior.