Layout changes when saving
I've run into a problem where my layout stretch changes are being lost when I save the file. They visually revert to previous settings as soon as I click 'save'. I've attached a video of this happening.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: 3224f34
(OS is actually Windows 11, not sure why Musescore reports 10)
| Attachment | Size |
|---|---|
| musescore-save-bug.zip | 704.65 KB |
Comments
Instead of a video, what we need is the score itself and simple but precise step by step instructions we can follow in trying to reproduce the problem.
In reply to Instead of a video, what we… by Marc Sabatella
No problem -- score attached.
How to reproduce the problem:
1. Go to page 3 of the score
2. Select everything from the first small note below 'Encore plus retenu' to the last rest of the following bar (i.e. the last bar before the page break)
3. Decrease layout stretch -- this will change the layout
4. Save the score -- this will revert the layout change that just happened.
In reply to No problem -- score attached… by Flup
Works for me (and I guess you mean section break, not page break)
In reply to No problem -- score attached… by Flup
But I do have a score that behaves like you describe. Drives me nuts...
In reply to But I do have a score that… by Jojo-Schmitz
If I reduce the layout stretch the score does shift slightly when saving. What is more, after saving the score is not marked as dirty but the undo arrow in the toolbar is active and clicking on it also makes the score shift slightly. It does not fully undo the reduce stretch operation; the content of the systems remains the same but their position is slightly different. Looks like a bug to me.
In reply to No problem -- score attached… by Flup
The spacing in your score is set up extremely strangely, which is part of the problem. almost every measure is stretched way (wider* than the default, which should never happen., Did you perhaps do that to try to trick MuseScore into ending a system early? Don't do that - just add system breaks (eg, hit Enter). So first thing I'd recommend is Ctrl+A to select all, then Format / Stretch / Reset Layout Stretch, then add system breaks as desired.
Not that those extreme stretches shouldn't work to some degree as well, but you're pushing the limits of what the spacing algorithms are designed to handle when you do that.
Anyhow, I'm not sure I'm following the specifics, as there are no page breaks at all on page 3, and there are five bars before the section break. If I select all five and reduce stretch, they fit on one system, and this is not reverted on save, not with 3.6.2 on Linux anyhow. There is a slight recalculation of the space between systems, though. That happens occasionally as some operations only do a partial relayout of your score in order to save time, whereas save forces a full one.
But again, reset stretch and system breaks and I think all your problems go away.
In reply to The spacing in your score is… by Marc Sabatella
Thanks for the detailed help and advice. I guess people will always use software in ways the developers never imagined!
I've been using stretch to get the spacing that I want, and to avoid awkward page turns.
So if I understand correctly, I should--
* use Style and/or Page Settings to get the general spacing that I want; and
* use system breaks instead of stretch to avoid awkward line and page breaks.
Is that better practice in Musescore?
In reply to Thanks for the detailed help… by Flup
Yes. Use system and page breaks at the places you want them, reduce stretch at places where you want to fit more onto one system, but there's no real need ever for increasing stretch.
In reply to yes by Jojo-Schmitz
I have no idea why I never thought of doing that but it makes it so much easier. Thanks so much!
In reply to yes by Jojo-Schmitz
If it's the case that "there's no real need ever for increasing stretch" then someone should be asking the question: why does MS allow increasing the stretch without limit? If it's wrong to do it, then the software shouldn't be allowing it. I say put a limit on it of 1,00. Otherwise you'll always have users who do it and wonder why the layout goes bonkers on saving.
In reply to I run into this problem too,… by neo-barock
OK, drop that "ever" from my post...
Of course the layout should not suddenly change on save, but if improper use of the "stretch" parameter makes it happen, that would be understandable.
However, here is a case showing that "stretch" is not the cause. I have a score in which the stretch has been reset. There are no alterations to any stretch in any measures. The score is on 3 pages.
So this problem is not to do with stretch. Somehow the layout is being calculated differently when the document is saved. That's very clearly a bug if you ask me.
In reply to This really looks like a bug… by neo-barock
It's definitely a bug any time layout changes on save, whether stretch is involved or not. So if you have such a case, be sure to submit that as a separate bug report with sample score and precise steps to reproduce the problem. Best to check to see if the bug still exists in a current MuseScore 4 build, though, since much of the spacing algorithm has changed and code with old bugs has been replaced new code (and yes, presumably, new bugs).
For the record, bugs with layout changes on save would generally be due to one of two factors:
1) Normally when editing a score, we lay out only the portion that has changed, to save (lots of) time. But occassionally the calculation of what has changed might be off. On save, we do a complete layout of the whole score, so if something was missed during editing, it's fixed now. The upshot of this is - the layout after save is the correct layout; the one you saw after the edit was incorrect and somehow didn't account for something it should have. Generally, these bugs are relatively easy to find and fix once someone posts a score and precise steps to reproduce the problem just a matter of understanding why the edit didn't trigger the amount of layout it should have.
2) Layout is based on "floating point" math - the binary equivalent of decimals - and as such can be slightly imprecise. Like how 1/3 can never be accurately represented in a decimal, it's 1.33333... and you'll never have enough 3's to make it correct. These small discrepancies add up (and worse, multiply up), so by the time you've calculated the width of a bunch of measures, it could be off by a significant fraction of a millimeter. Meaning, at some point there is likely to be a measure that either fits or doesn't fit on a system that is 200 mm wide depending on whether the final calculation for the width of the measures yields 199.99 or 200.01 mm or whatever. These issues are much harder to track down and deal with., in part because they end up being "Heisenbugs" - the details of the calculations can be different depending on whether you are examining the code under a debugger or not.
In reply to It's definitely a bug any… by Marc Sabatella
Hi Marc. The steps to reproduce are: open the score, touch anything, the layout changes, save it the layout changes again. And this happens in about every score of mine, so, really no clues anywhere ...
In dealing with problems of your type 2) above, I'm sure you're aware that one strategy is to use a "big number" library which allows data types having (almost) any level of desired precision, so you don't have errors in the first place. Another strategy, in case it hasn't occurred to anyone, is to track accumulated errors when doing important calculations by storing the difference between desired and actual values in parallel. Stored error values can be looked up and taken into account when doing calculations that don't involve the values directly but depend on the errors.
In reply to Hi Marc. The steps to… by neo-barock
Hmm, really? I’ve seen only one or two cases of this in my decade with MuseScore, none in the past several years. So if you see it often, probably there is some unique setting common to your scores that most people don’t use, and that seems like the likely culprit. Anyhow, since you say it happen to many scores, ir should be simple enough to attach one and five more precise steps (which specific element to click). Then we can begin to investigate, and to discuss further.
In reply to Hmm, really? I’ve seen only… by Marc Sabatella
Thank you, but I don't want to share my scores publicly. It's not every score, but many. I'll see if I can track down what causes it ...
I'm pretty sure I found the cause. Please see https://musescore.org/en/node/331065
In reply to Thank you, but I don't want… by neo-barock
If so, hopefully you can now create a sample score to reproduce the problem. If not, please consider trying to findi one of your existing scores where the problem happens somewhere in the first few systems, then just share a truncated copy of it (eg, everything after the first few systems deleted). Also keep in mind, posting here is not like posting to musescore.com - your score will be seen by only a small handful of develoeprs. And in case you weren't aware, it is fully protected by copyright law the moment your set it down - no need to wait for registration. So one way or another, I hope it is possible for you to find a way to help by providing a reproducible test case. Again, I've seen literally two cases of what you describe in 10 years, and none recently, so we really cannot investigate without an example.