Save a copy of full file very easily and have an option for full file auto save every 15 minutes or so.

[TeeDeeY]

Your idea

The save a copy function is nice and would be better if it increments a sequence number after it, like copy_005, then copy_006. Then, assigning a function key sequence makes it easy to save without a pop up menu appearing or any additional typing. The save happens and I keep on working. A hidden file can keep track of the next filename to create so it isn’t too difficult to maintain the number sequence, even in the hundreds.

The next step would be setting whole file auto copy every 15 minutes. Each file being worked on would be saved in a hidden directory every 15 minutes so as not to clutter the directory, but is easily found. A “delete older backups” option in the file menu could delete all except the last three auto saves.

The autosave as an initial default helps new users who don’t save often enough.

Problem to be solved

Many users on musescore.org complain that they lost their work. They don’t save their work constantly. Full file auto save as the default helps the program from getting a bad reputation when someone loses many hours of work. Or a file corruption occurs and the current file is no good. Or the cloud upload didn’t really save the file.

I constantly save using revision numbers. Sometimes I forget so auto save is helpful.

I use nightly builds. Having the backups can be helpful since they can crash more often.

Prior art

Apple Logic Pro has a different method. You can save your work under the same name and revert to prior saved copies. I have a setting of 6 versions at one site. You can define how many old copies to save. You don’t need to specify a separate file name to save it under, which is convenient. Separate file names using a number sequence would be better, safety-wise.

Musescore crashes a lot more than Logic Pro.

I’ve never had a corrupt file with either program but the posts for help keep coming up.

Additional context

Musescore files are small. Disk space is cheap. Why not save the whole file repeatedly? Using a new sequence could reduce a file corruption issue from spreading. Currently, if the last two saves in musescore are bad, the backup is bad. If there are many autosaves with different sequence numbers, then it’s likely a good version can be found.

Just don’t autosave during playback, which would cause a noticeable delay.

A common musescore file corruption issue is when a file is mostly all binary zeroes. A quick read back of all files for this type of condition could help detect a corrupt file and possibly cause an alternate save method to be used.

Saving all files with a temporary name, then checking the files for corruption, and then only renaming the files after passing the check could be helpful.

The point is to prevent lost work as much as possible.

[MarcSabatella]

FWIW, given that the main way people manage is to lose a significant work is to literally work for hours and never once ever save the file (because in this case the autosave file ends up getting clobbered by subsequent new scores), the proposal seems seem vastly overkill. The much simpler solution is to not clobber the autosave file for scores that were literally never saved. No need to duplicate basic operating system by building in a versioning scheme when OneDrive, Time Machine, and a host of other systems already do this for all applications automatically.

I recommending starting a discussion in the ƒeature request forum on musescore.org to gather more feedback on how the autosave system could be improved - like where it should be kept for scores that have literally never ever been saved, what naming scheme should be used, etc. I could also imagine a warning dialog popping up after the first 15 minutes or whatever if you’ve literally never saved the score yet, saying “this score hasn’t been saved yet - save now?” And thus reminding you how vitally important actually saving a file is.

[TeeDeeY]

Having safety overkill as default should not be a problem. Users can turn it off if they want. Their choice. Like driving without using a seat belt.

I’ve had earlier 4.1 or 4.2 versions crash. Auto save didn’t prompt for continuing multiple times. Nowadays, I am saving constantly because musescore does crash and does corrupt scores.

I am sometimes just transcribing but I am often creating new work. Every new thought is important to record so I am saving my work constantly. I change a file name revision quite often as well. If the filename version number (revision) was done automatically, a control-s would be very secure and easy because a new file is written out, saving a copy under a new name without asking me for a new file name.

If auto save was made extremely reliable, and multiple “independent” auto save snapshots were constantly saved, that would be more useful that the current method. If I could manually apply any of a number of auto save snapshots, it’s more likely that I get my work back.

This is a technical discussion. Most crashes and corruptions are not reproducible. I personally want the entire file saved. Hopefully some progress is made on auto save.

If auto save files could keep more data so that they could be run independently of the original and produce a score of “auto saved measures”, then I may be able to copy and paste the changes into something useful. I’d need completed measures to view in order to understand the new changes, which is why I’d hope for at least saving on the “measure” level.

Realistically, user discussions aren’t useful. The ones in charge decide, and that is what is done. Hopefully a big step up is done.

There is almost no economic cost to saving entire files in the background. The score can be saved quickly to RAM, and then saved to disk in sections in the background if some users are very sensitive to the saves. They can also turn the option off.

Again, having safety overkill as default should not be a problem. Users can turn it off. Hopefully those in charge will be willing to make a big step up from the minimal auto save currently in use, which also occasionally fails.

Pop up warning dialogs are not done by anyone. Just save the whole file and be done with it. It will be easier to program complete file saves rather than improving the current auto save, so complete file saves is the most realistic option.

[MarcSabatella]

It's not just a question of whether users can turn it off. it's a question of whether it's worth devoting significant resources to designing, implementing, documenting, and supporting a system that isn't truly needed, when that same effort that could be spent on things that truly make a more significant difference for a larger number of users. Especially since this particular proposal really shouldn't be necessary at all if the existing autosave functionality were just tweaked slightly (to better handle of case of users literally saving the score even once, which is the one and only case it doesn't handle well currently). And as mentioned, the versioning facility duplicates functionality most operating systems already provide.

If you saved your score, then there is an autosave file you can open regardless of whether you are prompted to continue or not. If you need help using the existing autosave system, please ask for help on the official Support forum at msuescore.org. If it turns out there is some sort of as=yet-unreported bug that you are able to reproduce where for some reason in some rare corner case the autosave file is not generated, then open an issue here of GutHub to report that bug along with the precise steps to reproduce the problem. But in general, the autosave system absolutely works and doesn't need all this extra complexity.

Anyhow, the issue tracker is not the place for brainstorming potential design ideas. Again, I recommend going to the official Feature Request forums to discuss this further and try to get some sort of consensus to bring to the table.

BTW, to be clear: I'm not in any position to say yes or no - I'm just giving my own personal take on this based on my years working on MuseScore development and support over the years. My hunch is that if you don't discuss this other users can come up with a better-formed proposal, it's very unlikely this proposal will go anywhere, for the reasons I have explained: it's just not a very good design or a good solution to the actual problem. But a well-thought-out proposal resuklklting from discussion with other experienced users might well be implemented. So again, if you care abut thiuas topic, I do encourage you to discuss it with more experienced users.