Saved score opens with a different layout
I've been experiencing changes in the layout of symbols such as hairpins and dynamic marks when saving a file and then opening it again.
The problem occurs when some of the elements are set as "automatic placement" and others not. Sometimes this is necessary since the full automatic placement is not satisfactory. One example of this is when there are some potential collisions (for instance, when there are two ore three ledger lines), which are correctly dealt with by the automatic placement algorithm, but the default rendering is not aligned with other similar symbols in the same staff. While this is not a mandatory precept, it is recommended (for example, by Elaine Gould).
The mix of automatic and non-automatic placement is a tradeoff, since automatic placement solves local alignment between dynamic marks and hairpins.
However, even if it looks well at saving, when opening again everything is messed up.
As a workaround, all symbols must be placed manually.
Comments
Update: The problem seems worse than I'd thought. Even placing my dynamic marks and hairpins manually and unchecking for all of them the Automatic placement feature, Musescore changes the location of those symbols in a seemingly random way the next time the score is open. Some of them remain at their original position but others change.
As a conjecture, perhaps there are other elements for which automatic placement is checked (a slur, for instance) which would require that other elements be placed elsewhere to avoid an alleged conflict, regardless whether they are set to be automatically placed or not.
If this is confirmed, it is a very serious problem (a regression respect to 2.x versions), since what a program should never ever do is change the document the user saved or thought was saving.
Unfortuntely i cannot provide an MSCZ example since when you open it you'll be seeing the modified version. So I show the result of image capture. When opening a perfectly neatly edited score I find this:
![Fixed-saved-opened.png]( "Fixed-saved-opened.png")
![Fixed-saved-opened-fixed_again.png]( "Fixed-saved-opened-fixed_again.png")
To be sure, automatic placement remains unchecked for all hairpins and dynamics as I left it when saving, but the vertical offset changed to 5 sp, instead of the intended 4 sp. The dynamic marks did not change, they have a vertical offest of 4.5, exactly as intended (for some reason, to be aligned with hairpins they must be 0.5 sp below). By the way, the background re-location process has produced a conflict with the ottava of the next staff, so if it was intended to prevent some (otherwise inexistent) collision it created a worse one). So I proceed to fix it again, manually reverting all hairpins from y = 5 sp to y = 4 sp. I get this:
I save the file, close it and open it again (or I export to MSCX and open it, the result is the same). I get exactly the same result of the first figure above (I don't repeat it to save space).
In reply to Update: The problem seems… by fmiyara
Please don't take this as a definitive answer, because I'm not MuseScore staff and not even a volunteer developer - just a user.
But I think maybe you are fighting the auto-placement unnecessarily. I attach a score created in MS 3.0.5, which achieves more or less what you want, without turning off automatic placement for any element and without any staff spacers.
I am reluctant to prove this point by "revert to factory settings", but from memory I think that back in MS 3.0.1 I changed the default Position Below for Dynamics and Hairpins to achieve a more level alignment. The screen shots below show my current settings:
![Format_Style_Hairpins.png]( "Format_Style_Hairpins.png")
![Format_Style_Dynamics.png]( "Format_Style_Dynamics.png")
And this is the output, which survives a Save and Quit:
![Hairpin_and_Dynamic_placement.png]( "Hairpin_and_Dynamic_placement.png")
In reply to Please don't take this as a… by DanielR
Thank you very much for taking your time to analyze my example (again!). You are right that I could have tweaked a bit the default settings for auto-placement. This certainly improves things a lot, but doesn't solve them completely. In this example, for intance, I would expect that all the dynamics and hairpins belonging to the staff were aligned. However, this doesn't happen between the first six elements and the last two ones.
For quite a while the auto-placement feature will be necessarily incomplete. This is just the first attempt and is promising (to be fair, I should probably say amazing) but not a finished or mature tool. In order to be able to be competitive with a professional human engraver much work has yet to be done. It already works well with the inmediate staff elements, which is a first and big step. Recognizing associated elements such as hairpins and dynamics greatly simplifies the musician's life and normalizes the final look of the score (a reatively easy improvement would be to recognize associated but not adjacent signs, such as the mf and the hairpin). But it should also recognize distant elements that could potentially conflict, such as the hairpin under the upper staff and the ottava above the next one. And should be adaptive, the position above or below should adjust to the situation to improve alignment.
And even when thoroughly accomplished, there will always be a marginal case that being infrequent could not possibly be anticipated by the programmers, so there will always be cases where a final touch will need to be human-made.
That's why I insist that the application should not change back things that have been humanly altered. Probably it is not very difficult, just keep auto-placement for all untouched elements as if the other ones didn't exist, and place the other ones exactly where the user placed them.
In reply to Update: The problem seems… by fmiyara
As usual, there is little we can do to help from just a picture, we need the actual score and steps to reproduce. But as it is, from the picture, I am guessing you are seeing the effects of a bug #283312: Hairpin position changes on reload if horizontal offset applied on small staff that is fixed for 3.1.
In reply to As usual, there is little we… by Marc Sabatella
Thank you. Do you think that if the score is saved in 3.0.5 with all changes made and looking right, when I open it with 3.1 beta I will see exactly what I saw when saving? Or rather I'll have to fix everything in 3.1 beta? In the latter case, If I open again in 3.0.5, will it be correct or the bug distorts the way the score is displayed?
In reply to Thank you. Do you think that… by fmiyara
This specific issue with hairpins (and other lines) on small staves that had horizontal adjustments shifting on reload is unfortunately due to recording the offset incorrectly both when writing and reading the file, so I don't think it's likely to be corrected automatically. And a score containing this type of error corrected in 3.1 still may not look right if loaded back into 3.0.5. There are other issues with small staves that should be fixed automatically when loading into 3.1, but again, the issue will still affect attempts to view the score in 3.0.5.
In reply to This specific issue with… by Marc Sabatella
OK, Thanks for the details. I think when I'm ready with the composition I'll take the risk of formatting it in 3.1 beta while keeping a 3.0.5 backup just in case.
I am still having many persistent problems of this type in 3.6. I’m not sure it is only closing and reloading that does it. Sometimes I make a change that reduces the number of systems that will fit on an early page (though I don’t think it should) and when I find a way to restore the pagination, later hairpin adjustments are gone. It is so bad that I am going to have to use an earlier pdf with known errors rather than a later, much corrected successor with I suspect, many more errors (both attached). In the later MS score, see the crossing hairpins under the final tremolo, many hairpins lower than I want in the rest of that system, on p24 cl hairpins too high in mm17&18 and piano slurs too high in m21, etc. These are as I want them (and made them) in the pdf. I unfortunately don’t have a MuseScore file for the pdf, but I promise you the successor was made strictly by adjusting the file from which the pdf was made.
Since automatic placement seems to play into this, I will add that sometimes I adjust repeatedly with it on and nothing happens until suddenly the hairpin (or other object) moves a long way. Sometimes I wind up turning it off, or off and on. Sometimes other things (like a p or other hairpin) move with it, sometimes desirably, sometimes not, but always mysteriously. Sometimes moving a hairpin undoes a move I just made in another staff. I haven’t found an explanation for what happens in these situations.
You’ll probably say it belongs in another thread, but in Var V, I have been unable to find a way to have the Bb clarinet in 5 sharps in the score (concert pitch) and 5 flats in the part (transposed pitch). Don’t bother telling me I want the transposed pitch in the score, because I definitely do not. (I’m an experienced amateur pianist, not a conductor.)
In reply to I am still having many… by jwpratt
Sorry to hear you're having problems with layout! Since this doesn't happen in general for most scores or most users, presumably it's going to turn out to be some unique thing about your specific score or the specific way you go about editing. So if you ever do figure out precise steps to reproduce the problem, let us know so we can begin investigating and hopefully find a solution. BTW, note that any problems reported in this particular thread are almost certainly unrelated - the picture shows a specific 3.0.x bug that was fixed several years ago in 3.1.
As for the tranposition question, yes, indeed, it would have been better to start a new thread for that. Next time :-). And actually, I totally understand preferring concert pitch scores; in many case I do do. What * would question is whether clarinet players would prefer five flats over seven sharps in their parts. Most I know would prefer the sharps, simply because they are so accustomed to seeing lots of sharps because of the transposition of the intrument and similalry are very not used to seeing lots of flats. But if you've checked with your clarinetist and they definitely do prefer the five flats, just go to Staff/Part Properties and set the the preference for key signatures to flats there. You'll need to change the enharmonic spelling too of the notes themselves; Ctrl+J allows you to do that without affecting the spelling in concert pitch mode. Another possibiltiy is to insert an instrument change there, and set it to transpose by diminished third instead of major second (same dialog).
In reply to Sorry to hear you're having… by Marc Sabatella
Thanks. So far I haven't reproduced the layout problem. I suppose it will happen just when I'm not paying close enough attention to know what I did :-(.
I don't have a clarinetist currently, but since your suggestion works, I don't think we need another thread :-). I'm surprised I didn't try it, but maybe I worked only on the score, not the part. Anyway, I've made an alternative in flats for that var for the cl, and since you say sharps are preferred, I am happy to leave them that way in the main part. Thanks again.