'source' tag stays the same when using "File Save As" to create a new file - causes publish error
Reported version
4.0
Type
Functional
Frequency
Few
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
1) File - Save As - create a new score with a totally different name
2) Use "Publish to musescore.com" option via Musescore application
3) The new file overwrites the old one on Musescore.com even though it has a different name. Causes major confusion. Problem results because the "source code" is the same for the new file.
Suggestion: give files new source codes when saved under a new name.
Comments
Counter argument is that some users rely on the old behavior
Workarounds are to either manually empty that tag (in File > Project properties) or to untick the box at "Update existing score" when saving online.
Or to manually upload the score
I use the current "save-as" behaviour and have never seen it cause any publish error. What error message do you see? This behaviour is exactly what any "save-as" should exhibit. A "save-as" that made changes to the file contents would be counter intuitive.
The tick box for "updating existing score" is my confirmation that I am indeed updating an existing score, (as expected), and not inadvertently creating a new score online. You could use this as a warning if you are not expecting to update an existing score, and then untick it to create a new score.
In reply to I use the current "save-as"… by yonah_ag
It's not just me. Another user on the support discussion plus a user on Facebook reported the identical thing. It's not an error message, it's just an error period.. Musescore publishes the new file by overwriting the previously uploaded score. The file name shown while publishing the new score matches the new one, but the description is identical the prior one. And then the perviously uploaded score disappears from your "my scores" entirely because it's been overwritten.
In reply to It's not just me. Another… by bigeasyboys
It would be counter-intuitive and unlike "save-as" in any other software that I have used.
It is not an error: it is correct design, This behaviour is exactly what I would expect and I make use of it.
In reply to It would be counter… by yonah_ag
I disagree. I will reply the way I respond to Marc on the Facebook group and leave it that. I was encouraged to file this suggestion ticket, so I did. Leaving it alone from here. I had never used the option to publish directly to Musescore.com from the app itself in prior versions, but I don't remember it being an option that was so prominently featured, so perhaps that's why it's becoming more of a problem for users now.
--
It's a very reasonable expectation that when you create a new file with a NEW name, there would be no reason for anything to be overwritten or updated, since the file new is unrelated to the previous one.
I'm not saying there's anything wrong with the design or that it's not user error. I'm just offering a suggestion that Musescore has the ability to save users many hours of headaches, confusion, and frustration by better communicating what's happening.
Since literally 3 people have posted about this very same issue in just the past 2 days alone, it doesn't seem to be an uncommon problem. I'm convinced that my other problems in losing my saved work were directly related to this issue, so it might lead to other issues. Regardless, I will follow your advice and only use the template method to create new files. It's up to you and the design team whether to follow our suggestion to help others avoid similar trouble.
"Save-as" is an internal app function equivalent to an operating system's file copy and, just like file copy, it should not change the file contents but only the file name. I rely on this when uploading milestone iterations of a score, saved with a new version number in the file name.
It is a lack of user understanding which needs to be addressed here so maybe an additional tick box could be made available on the "Save-as" dialogue to allow the source property field to be optionally cleared. A link on the dialogue, (next to the new tick box), to the handbook could provide the "better communication" that you refer to.
(I have only ever published from within the app and this option hasn't become any more prominent since version 2 of MS but I don't know about v1).
Perhaps a Save as New Score option could be added here:
And this option could reset all score properties, not just the source field.
The handbook could add:
"retaining score properties" for Save As and
"resetting score properties" for Save as New Score