Save to next file in sequence

• May 4, 2022 - 12:45

I have asked several times about a possible history feature for MuseScore.

However here I'm going to suggest a very quick fix for something which I personally would find very helpful. It might be possible to automate this outside MuseScore, and if MuseScore eventually comes up with something better this might get in the way, but essentiall it goes like this.

Choose a number - 0 or 1 will do.
Open a new folder to work in - for a piece under development.
Make a name for the piece to work on.
Create a MuseScore file using that name. Append the number to the file name.

The next bit would be the useful part.

Define a new Save operation, which saves the latest version with a new number, and increases the number by one each time it is invoked.
This would result in a folder with a whole bunch of numbered working files, and during development this could be very helpful.

Obviously this can be done manually, but it might be great if something like this could be inbuilt.

Some people might not like this, or want it, but others might find it very helpful.

Later the folder could be pruned down, or discarded if no longer needed, once all the development work has been done, though it might be useful to keep for a while.

Teachers and others might find it useful, as they could generate new examples very quickly, and compare them.


The only problem I have with this is that I wouldn't want it to happen automatically. Yes, I have folders of numbered files. I only add a number if I've made significant changes. For example I might get part through working on a piece. I save my work. Later I open it and continue to add to it. Then save using the same title. I might even finish and save under the same title. Then I go back and redo some parts. That gets saved with a "1" at the end of the title. Later I make more changes and the files are numbered accordingly.
All I'm saying is that with an automatic system, I could have a folder with 20 or 30 files in it. I think I would want to control whether or not it happens. But then that adds a step which is what you are trying shorten.

In reply to by bobjp

I have now started to use a different modus operandi - slightly more organised for new compositions.

Essentially it goes like this.
1. Create a new folder. Name it with the name of the new piece.
2. Create the baseline MS files - and any needed files to aid with the work.
3. Start creating the new score.
4. Whenever there is a significant or interesting change to the score - use Save As with a number - generally one more than the last used number to the dedicated folder.

I can easily get over 30 copies in a day - but there turn out to be many advantages of this approach - some slightly surprising - though obvious if you think about it. One is that by having so many versions - if there is an error in one it's possible to compare with another similar one - by viewing the scores side by side, and then making a decision as to which to modify, or copy over to the other. At that time/point there might need to be a decision as to what file name to use - or an out of sequence number, or a modified number - such as 21b.

I guess if I were even more rigorous I'd make a note of the versions - with a comment each time - but so far I've not done that.

Sometimes I change the instrumentation - and a question then arises as to whether to change the file name - to indicate the instrumentation change - or not. So far I haven't bothered, but then a separate note to myself indicating which numbered files have which instrumentation might be useful.

As many MS files are not really that large - at least for smallish pieces, there really isn't a great problem with having folders with very many different versions.

If a new version has a very significant change from other versions, then create another new folder - again named with a different and distinct name from the original folder, and carry out the same kind of process with that.

In reply to by dave2020X

I use a similar work flow when composing, but usually I don't go above 5 or 6 versions per day but easily have 30+ by the time a piece is finished (are pieces ever finished? or is the composition process just stopped when inspiration dries up and the piece is "good enough"?)

Returning to your workflow. You say "if there is an error in one it's possible to compare with another similar one - by viewing the scores side by side". Are you using this useful facility. It is quite well hidden.

Your idea is interesting but it is so easy to manually update the number when saving, Just edit the suggested name. I also often use sub numbers so that I can follow two different ideas e.g. score 05 becomes score 05 01 followed by score 05 02 etc. while the main idea continues as score 06 etc. I think github would probably suit my purpose well but needs some effort to become familiar with it and to understand whether migration all work in progress would be worthwhile.

In reply to by SteveBlower

I believe I have looked at the score comparison tool before - and didn't find it all useful - but maybe it's changed. Last time I looked it seemd to be doing a low level comparison - rather like trying to compare two computer programs, but only having access to machine code ..... [and yes - in case you ask - I've done that too, and I knew people in the past who used to analyse OS core dumps ...].

I'll check it out again - just in case it's improved, or I was looking at the wrong tool.

I agree that with a bit of discipline it is possible to come up with quite a quick workflow, and do some of the processes manually with only a little extra effort.

Using a dedicated folder for each piece is helpful too.

Up to now I did maked changes to scores "in place" - and use the forward and backward redo operations - which work as a kind of history operation - but it's still not that reliable - so I'm thinking that even making quite small changes justify a save and a new number. OK - saving ever minute change may lead to a lot of files to search through - and it would still be good if a history could be stored with each one - but I have been caught out before by having tried out ideas, then later wanting to use them again - but not been able to find or retrieve them. I have also lost pieces because of MS crashes - so this approach makes that much less likely.

In reply to by SteveBlower

I think I see what you mean - sometimes. The highlighting seems very weak. The only one I could be sure of was a sharp sign being replaced by a blue natural sign. The text list seems almost useless for anyone other than a forensic expert.

This really is not at all obvious - though I agree that in some situations it may be quite helpful.

Not exactly what you have asked, but a first step would be to install git (small and free), make your score folder a repo, and schedule a commit at regular interval (such as every night).
That way you're sure you can go back as many days as you need in your versions.

In reply to by frfancha

Not sure about git - but I'll look out for it. How does it compare with Apple's own TIme Machine - which for the most part is completely useless [BUT it did rescue my system when it got completely trashed a month or so into the start of lockdown ..... THANKS APPLE!!!! :-) ]

Very occasionally I have been able to rescue single files, but it's quite hard, and it also requires a certain amount of checking to make sure it doesn't overwrite other files - though actually it does seem quite good - and will in fact usually give an extra number to files which might conflict. The problem is that one has little control over when snapshots are taken on day 1, and on subsequent days I think snapshots are rolled together so - as you say - that kind of behaviour is not quite what I want.

I'd be interested to know though if this has the same or similar functionality to Apple's TM.

Using git is certainly a decent option if you want full-fledged revision control. It's pretty techy, though, probably not something someone who isn't already using it in their programming work would find very friendly. Works great though. Save as much as you like while working, then when you have a version worth holding on to, use the git tool to commit that as a new revision.

If you're OK with simply making every single save a revision you can restore to, simply saving to Google Drive would accomplish that - up to whatever limits it imposes. Not sure how the new cloud service that will be offered by MuseScore 4 will work, but that could prove an interesting alternative as well if it helps history.

But I like the simple numeric scheme. And as mentioned, a plugin to do that should be pretty trivial. That also solves the issue that one wouldn't normally want literally every single save to be kept forever, just the ones that correspond to "landmarks" along the way.

Do you still have an unanswered question? Please log in first to post your question.