3.6.2 File Management: Loading old score causes it to be flagged as "modified"
Since the 3.6 upgrade, whenever I load a score created with a previous version, it gets flagged as "modified". This makes it very difficult to distinguish between a real change I've made to the CONTENT of the score from just a FORMAT update required to conform with the standards for the latest version. If I accidentally save a score with no content change, Windows will change the "last modified" date for the file.
iWhy do I care? Well, I have hundreds of MuseScore scores, and to make sure that anyone I'm sharing a score with is working with the same version, my standard footer includes the "last modified" date as well as the title. (I also find it very helpful to be able to sort all scores by "last modified" date. But if that date doesn't represent the actual last date the content was modified, it's worthless.
Yes, I know it's possible to save each existing file in the new format and then manually (e.g.via Windows Power Shell) change the "last modified" date to the previous status. But that's a huge clerical effort and very prone to manual error.
Any suggestions for how to automatically update old scores to the new format WITHOUT changing the "last modified" date?
Thanks for any help anyone can offer.
If know that Is there anyf everything
Comments
A change to style settings is a change, and if you want that change to be seen by the next person who opens that score, you need to save that change. This is true whether you do the change via a dialog when first opening the score or whether you do the change in Format / Style or in the Inspector.
So making the change "stick" requires saving it, and saving it normally updates the modified date. Saving without updating the modified date would be a lie, but there can be valid reasons for wanting to tell that lie for sure. If you wish to do this, your OS probably has ways of resetting the modified date, eg in Windows Explorer.
If you do not wish to update the style settings, simply choose to keep old style. That choice itself would be remembered if you elect to then save the score, but if you don't elect to save it, Musescore will have no way to remember which choice you made, or even that you had ever previously opened that score at all. So it does offer to save the score, but you can freely choose not to. If you know you will not generally want to update the style settings for any older scores upon opening, you can also check the box to not show the dialog again when opening a score.
In reply to A change to style settings… by Marc Sabatella
I'm sorry if I'm being dense, but I just don't understand EXACTLY what "changes" are automatically being made to style settings just because a score is opened. Perhaps that's because I do very simple stuff (treble-clef-only "fake-book" type scores, with chords) and a lot of the very elegant new features for handling multiple-instrument/voices scores don't apply to me. So far, the only substantive change I've noticed is that whenever I create a new score, the new "vertical-justification" option is always set to "on", even though I've explicitly saved the "off" setting to the style sheet where MuseScore gets my individual style settings for new scores; I have to manually turn it "off" in each score.
As best I could understand it, the only thing the open-score dialog box (which I turned off) asked was whether I wanted to use the new fonts, and right now I don't see any reason I'd want to. (All my effort is focused on trying to enter pitches, rhythms and lyrics correctly, so I'm not hugely concerned with typography details as long as stuff is legible.) I can't see why opting not to use new features would be considered a "change". But perhaps you can direct me to somewhere that explains in more detail which style settings are changed just by opening an old score.
Thanks for your help.
In reply to I'm sorry if I'm being dense… by MandyWh
It is either keeping the old (and no longer default) fonts or taking the new fonts, in either case changes to the score.
And yes, I don't like this and believe it could have been avoided and said all that back when it got implemented this way. But it now is the way it is.
In reply to It is either keeping the old… by Jojo-Schmitz
I just hope that for future MuseScore upgrades, more weight will be given to user needs for file management. I've been involved in programming and managing computer systems since 1965, and one of the most painful lessons everyone had to learn over those years was the importance of version control. If every program's source-code got flagged as "changed" just because the operating system had a new compiler installed, I (and many of my friends) would have been hauled off to the looney bin long ago [g].
In reply to I just hope that for future… by MandyWh
Updating the compiler might indeed require to recompile the sources, to benefit from improved optimizer of fixed bugs.
Just opening a pre 3.6 score in 3.6 does not update the timestamps (not the 'last modified' one at least), saving though indeed does (and rightfully too), and in this case not only the timestamps but also the content (of the file, not what you call content though)! As you could verify by opening that score with any pre-3.6 version.
Nothing to do with file management. If you didn't change anything, and you're not bothered about getting asked the same question on next open, just don't save.
But yes, it is now difficult to impossible to tell whether the score was modified by you or by the 'import'. As said above, I didn't like the idea back then and strongly opposed and still believe would could have done without.
But it is too late now to cry over spilled milk I guess.
In reply to Updating the compiler might… by Jojo-Schmitz
Recompiling a program doesn't necessarily require modification to the source unless [a] the new compiler enforces standards so that violations that previously were acceptable no longer will compile correctly or [b] users want to take advantage of new features that the compiler now offers. I can recall instances where project managers used a valid "last-modified" date to check that the source code of all programs had in fact been manually modified to comply with new compiler standards or external conditions.
It seems even more important for MuseScore, when many extremely useful play-back features modify the actual score rather than a separate set of play-back parameters. E.g. In learning complicated melodies with weird intervals, I find it very helpful to play back a score with chord-play turned off, but I don't want to modify the actual score, so I have to remember not to save the file when I'm done. I don't really understand why the playback parameters aren't stored separately, but I accept that that's the way the system is designed, so I've got to learn to live with it.
As you say, there's no point in grumbling about things I can't change. Maybe I'll explore the facility for writing plug-ins. I'm hoping I could figure out a way to [a] assign some field within Score Properties to hold "last-date-modified-by-user" and then [b] whenever I close a file that's flagged as changed, it could ask me "Is this a content modification?" and, if I answer "yes", update that field. Then I could have that field be the date displayed in score footers. (I might also see if I could create a plug-in to update the "Score Properties" source field with data from another field. When I started using MuseScore, I don't think "Score Properties" had a "source" field, so I used the "Arranger" field to record my sources -- fake books, sheet music, downloads of MuseScore user scores, transcribed from audio, etc. I'd like to move all that info to the "Source" field, but not enough to do it all manually [g].) I haven't a clue as to how feasible that may be, but at least I'll try to find out.
Thanks very much for your helpful insights.
In reply to Recompiling a program doesn… by MandyWh
"When I started using MuseScore, I don't think "Score Properties" had a "source" field..."
I think that it probably did: certainly MS2 had the Source field. At first I used to do exactly what you are apparently trying to do: to use the "Source" field to document where you sourced the material. This is not a good idea!
The Source field is used to record the URL where the score is stored on musescore.com (when you first save your score online). So any content you place in "Source" will immediately get overwritten by the score's URL during the first Save Online.
The fields in Score Properties are documented in the Handbook here:
https://musescore.org/en/handbook/3/score-properties#default-tags
In reply to "When I started using… by DanielR
I'm pretty sure MuseScore 1 had a source tag too in some form or shape.
In hindsight "url" might have been a better name
In reply to "When I started using… by DanielR
Whew! Thanks for the info. It was just dumb luck that I didn't notice the "Source" field when I started using MuseScore [g]. (I did purchase and read the Manual to begin with, but there's so much to absorb that it's hard to remember it all)
For the vast majority of scores I'm creating, there's no arranger involved, so the "arranger" field was what I decided to use. I guess if I ever get around to tidying up all my scores, I can create a new "SourceInputs" field within "Score Properties" and move everything that's now in "Arranger" to that field. Btw, the Source field as now defined wouldn't work for me, since I often have multiple sources for a score (e.g. for melody, chorus, verse, chorus, lyrics. Right now, I've been working on a vocal fake-book-type score for Clifford Brown's "Joy Spring", for which sheet music doesn't seem to be available to purchase anywhere. (When possible I do my best to respect copyrights.) So I've combined information from two MuseScore downloads -- melody and lyrics from a vocal score without chords by Marzena Debska and chords from a piano score by D.D. Shatalov. I also used a non-MuseScore posting of a Real-Book page to double check both the melody and chords, and I plan to double check it against some performance audios to fine-tune the details.
In reply to Whew! Thanks for the info. … by MandyWh
purchase ... the Manual: ? The handbook is for free, online (most up-to-date) and in PDF form (updated to match the online version daily), from https://musescore.org/en/handbook
In reply to _ purchase ... the Manual:_ … by Jojo-Schmitz
Guessing she means my book :-)
In reply to Recompiling a program doesn… by MandyWh
Yes, your compiler analogy is not a good one indeed.
In reply to Recompiling a program doesn… by MandyWh
I suppose things could have been designed with "sidecar" files to record things like style or mixer settings for a score, so separate file-modified dates could be maintained. But FWIW, I've been working on this project over ten years now and recall a single instance where anyone ever brought this up or requested it before, nor can I think of a single other notation program that does this, nor any other similar program. Only example I can think of are image management programs that work with "RAW" camera files, where processing setting and other metadata do generally need to be saved separately because the format itself is essentially read-only.
It's not a bad idea though, so feel free to submit a formal Suggestion to the issue tracker for it!
In reply to I'm sorry if I'm being dense… by MandyWh
No changes are applied automatically if you select "Keep old style". So, if you select that, you don't need to save the file - nothing is changed. MsueScore will prompt you to save anyhow only so it can record the fact that you did indeed elect to keep old style so it won't have to ask again, but there is no loss in simply declining to save.
If you do choose to update the style, that's a change. Like any other change, no different, no way it could possibly be different. If you load a document into a word process then immediately change the font size, that's a change you need to save if you want it to stick.
Regarding the justification setting, if your scores are mostly lead sheets, you shouldn't need to mess with custom MSS files. Just create and use a template. That is, set up one score as desired, save it your Tempaltes folded,r then select it from the list instead of whatever you are actually selecting (Treble Staff?) when creating new scores.
In reply to No changes are applied… by Marc Sabatella
?? Of course does the score get changed when sou say "Keep old fonts", and save: the old fonts and old default settings (anything that isn't matching the new defaults) are now getting embedded into the score.
Hmm, OK, apparently not. But one thing does get changed: a new meta tag gets added (see File > Score Properties),
mscVersion=3.02And some more...:
A few of those of those changes may be specific to this particular score though.
The Score Comparison Tool misses all but the added tag.
None of these changes reall harm though (none but the very first: that one is responsible for pre-3.6 versions to complain that you're using an too old version, but just ignoring that and your score looks as it did before)
In reply to ?? Of course does the score… by Jojo-Schmitz
Well, yes, in terms of what needs to get written to the file in order to record that you made that choice, yes. The most significant thing there being, the usePre_3_6_defaults tag - that's what tells MuseScore next time not to apply the new styles settings, and just as importantly, not to ask about it either. That's why I said if you want MuseScore to remember the choice, you do need to save. But the point is, the style settings themselves are still as they were, and thus, nothing is really lost if you choose not to save. It just means MuseScore will ask again next time.