Checkpoints

• Jul 25, 2021 - 09:10

Sometimes while trying to write music I feel that a system of checkpoints might be helpful.

Not sure if this has been suggested or discussed before. The idea is that if working on a piece, and something seems to have worked out OK that the file could be "checkpointed" - with perhaps a comment put in place to remind the author.

The intention is that this would help people who do "in place" changes to pieces, which may be disruptive, so that the ideas which "work" could be retained, but would avoid having to scan through all the less successful changes subsequently.


Comments

Or you could use Add > Text > Rehearsal Mark for your checkpoints? (Ctrl+M on Windows)

Rehearsal marks are easy to jump to as well.

In reply to by DanielR

Thanks for the suggestions - both. I was thinking of something a bit like a Wiki. The problem with creating new files is that new versions tend to proliferate - and aren't bundled together, whereas a Wiki can keep related date together with date stamps - and possibly comments for each check pointed version.

I personally do use Rehearsal Marks - and I do also keep file copies - but a Wiki approach would seem to me to have many benefits for things which change quite rapidly.

Up to the point when a file is saved in MuseScore many changes are saved - both forwards and backwards in time.

I think these changes are lost when the files are saved. The implication of this is that there is a history list associated with a MuseScore file - so if this were saved when a file is closed, it would be helpful, but it would still require effort to scan through the history list to find possibly interesting variants of pieces being developed.

If there were checkpoints put into such a history list - and it was persistent across file openings and closings, then some might find that very helpful indeed - particularly if it were suitably annotated.

It would also mean that if files were shared with others, they could also have the benefit of different versions effectively stored in one file.

Obviously if one is only interested in a finished "product" there is little point in this, but if one wants to consider intermediate versions in a creative process, then this approach could be very helpful for some people.

In reply to by jeetee

Maybe - maybe not. I don't see why it couldn't be done, and equally I don't see why it shouldn't be done.

However, do you know how easy it is to set up a local git repo? I don't - and if it were simple I'd probably have a go. Of course if it turns out to be easy, then perhaps I would offer to do it for MuseScore. I will ask around.

In reply to by dave2020X

It's not hard if you are technically inclined.

I'm not opposed to seeing such a feature added, but as for why it "shouldn't;" be done, generally it is considered bad design and practice to reproduce in an application what is really more logically something that should be implemented at the filesystem or OS level. Because then you end up with a mess of different user interfaces to the same basic functionality. Better to design and implement it in a way that the same approach can be shared between the multiple applications that need it, versus needing each application to invent their own way of doing it. So a Git-level solution really is the better way to go, but better still if major OS vendors would implement that directly.

In reply to by Marc Sabatella

Nevertheless one approach might be to implement a feature, such as checkpoints, in an application - such as MuseScore - and then if it turns out to be useful generally move it out to the OS level. The current approach based on an "ideology" is going nowhere as most people have no idea whether they might use a feature like checkpointing or not - or if they would, they don't have the skills to implement them.

Otherwise developments aren't going to happen.

Unix had some great features, which I used to use extensively, plus also batch processing. It wasn't perfect, but there were things which could be done with that and the toolset available which most people now either don't understand, or are unable to access - unless they are systems developers. Another great system was Yahoo pipes - yet that also became obsolete. Nowadays so many people want to have "hands on" and WYSIWYG systems - which are great for some things, but if you wanted to get a lot of work done quickly then using systems level tools plus batch processing on a large scale would be very much more effective. To some extent that fits in with your argument that some features should be at a system level - but it that ain't going to happen, then if they can be done at the application level, then why not?

In reply to by dave2020X

Microsoft Word offers something similar called "Change Tracking" and it really only works because it's all contained in the document and managed by the app rather than the OS. This makes it ideal for collaboration but also gives some history control for individuals.

You can switch tracking on and off so you can wait until a document has reached a particular stage before starting to track changes.

This support page would provide a good spec for implementing change tracking:
https://support.microsoft.com/en-us/office/track-changes-in-word-197ba6…

In reply to by yonah_ag

Indeed - that Word feature can be really useful in a collaborative team, as it's possible to see who makes changes, and to either accept or reject each change.

Features like this aren't always useful - perhaps because of the way they have been developed - or the way they are used. For example, some photo editing packages and perhaps also design packages allow both forward and backwards rewind of editing steps. That can get confusing, and if one looks at a graph of changes, then things usually work up to the point at which one wants to go back, then forward to a new place. However, even though that can be tricky, it is a lot better than not having such a feature at all. Tools like Affinity Photo and Affinity Designer (I'll have to check this one ...) do have such history features. I think Photoshop does too, and on reflection - but I'd have to check yet again - maybe Apple's Logic and Final Cut Pro packages can do things like that too, though not necessarily in the same way.

In reply to by dave2020X

I don't know that the idea of versioning file systems is going nowhere. Windows supports this to some extent out of the box, Chrome OS does as well. Probably Linux has a way of doing it, and I think macOS does too via Time Machine. It's just that it isn't as full featured as Git, and not as universally understood or well-exposed as a more fundamental concept like that of a tree-structured directory, which all the major OS's support in virtually the same way and make very clearly visible to all users.

Anyhow, my point is that if enough people think it's valuable, then I think the best place for them to apply their voices in hopes of change is to the OS vendors, as there are only a handful of them, as opposed to trying to contact thousands of different application vendors. Some small percentage of those eindividsual applications might go ahead and implement it, sure, but that will help only the small minority of people who happen to use those programs. Better for society to spend that same effort trying to get the OS vendors themselves to offer it.

Another way of looking at it - there might be only half a dozen MuseScore users who'd make use of this, but combine that with a few dozne Finale, Sibelius, and Dorico users, plus hundreds of LibreOffice users, thousands of Office users, etc - it's actually much easier to get enough people to request a feature like this at the OS level than to find enough user of each individual application to implement it. And, it requires only a couple of dozen people total to implement it at the OS level, as opposed to the hundreds or thousands of people it would take to implement it at the application level.

In reply to by Marc Sabatella

I do want to keep pushing on this.

I have found that if I leave MuseScore open - don't close my machine down - I can make changes to scores - and roll them back. That implies some form of history storage within a MuseScore session. I don't see why that can't be saved (perhaps optionally) when saving and closing MS down. Checkpointing with markers might only be a small - but hopefully helpful - change to make.

Regarding moving this kind of functionality out to the OS level - that might indeed be helpful - but with big caveats. You mentioned Apple's TIme Machine. I use it sometimes - though not so much currently. I should do. It's not that easy to use and many users have commented that it doesn't always work, and that other means of ensuring backups - such as Super Duper and Carbon Copy Cloner can do better jobs. Having said that, it just so happens that last year I had a major failure on my laptop - due to trying to install a web camera and failing because seemingly of a bad driver. That wiped the whole of my machine out, and the email, but as I'd turned on TM the day before - having not used it for some time - I was able to recover almost all of my work. It did, however take at least a day - most of which was CPU time. I have hardly ever found TM to be useful in other respects - though I'm grateful that I was able to recover almost all my data because I had it installed.

I doubt that trying to move this kind of history feature out to the OS level is in reality going to come up with quick and easy to use solutions, and in any case the OS developers have different agendas and useful features could change rapidly if they decided to make significant changess.

In reply to by dave2020X

The way undo is implemented cannot survive save/reload - it involves all sorts of data structures that were never designed to be written or read. Not saying it couldn't be completely rewritten, but it would be a monumental amount of effort, so not likely given there are quite a number of other higher priority things to work on.

It is certainly possible to implement an interface to show the undo stack and allow rolling back to different points, much as is done in a handful of other programs. That would probab;y only be a couple of weeks effort for someone motivated to give it a shot.

In reply to by dave2020X

I mentioned Time Machine last because my sense it is indeed the most awkward The facilities built into Windows and to Chrome OS are quite simple and effective already, but still, not very well exposed.

I see no reason to expect that a bunch of random application developers would be expected to do a better job of designing such a system than people who actually special in such things - OS designers. So if you aren't happy with how Apple did, I would be even less optimistic about how people whose expertise is music notation and not filesystems would do it. And just because one particular implementation by people who should know better wasn't all that great doesn't mean you give up on the concept or ask less qualified people to take up the task. it just means you have good data on what deficiencies need to be addressed, when you take your request to the people who are in a position to address them - the OS people.

Hmmm... When I'm writing, there's a good reason I might go back and rework a section. That's because it wasn't right. So it is overwritten and gone. Everything after that depends on the new section. Now, if a piece is going to take several sessions to complete, I will save and number each session. Sometimes I will do some touchup after a piece is finished and again number them. But I can't imagine saving every little change.

In reply to by bobjp

I agree that saving every little change would almost certainly be counter productive and pointless. However, having some ability to rewind - or go forwards could still be useful.

I still don't know whether that is in fact already a hidden feature in MuseScore - as long as files aren't closed out. Perhaps one of the development team can inform me. It seems to me that many things are in fact saved within a session, so it oughtn't be too difficult to put in markers at different "save" points. Then if that were done, users could decide whether they found that useful or not.

At the moment it's mere conjecture on both sides that "it would be useful" - vs "it wouldn't be useful".

FWIW I once spent weeks writing a program which I thought might be very useful, but when I'd got it written and started using it found that it wasn't really that helpful at all. However, without actually doing that work I'd never have discoved that.

Sometimes ideas take a long while to come to fruition - including examples such as video phones and video conferencing. For many years there were attempts to implement video phones, and also some attempts to actually use them. The conclusions, from some of the better trials was that "nobody wants them", "people won't use them", or that it would be too complex, too expensive etc.

Roll on another twenty or so years, and now hordes of people are desperate to use mobile video technology to keep in touch with others.

In reply to by dave2020X

Nothing about the undo stack is saveable in any way shape or form. Not without a complete rewrite.

No one denies that this OS-type feature is useful, that's why several OS's provide it. And why there are utilities like Git that can be layered between the OS and the application to provide more flexibility and control across all applications. So the question isn't whether version control is useful or not - of course it is. The only question is whether it makes sense for thousands of application designers to have to design and implement it on their own, or whether it makes more sense for those people who want the feature to use Git or a similar facility that already exists and is well-designed for the purpose and works across all applications and systems.

TO ALL;
This is written and meant only in jest to lighten yet another Covid infested day ... and with all due respect to all about this issue.

Why don't we all learn to write like Bach, who, at least according to the "lore of history", wrote music exactly the way he heard it in his head. He was just his own secretary writing the notes that his brain was dictating ... correct the first time on the fly. Same was true of Mozart, Mendelssohn, and probably others of whom I have not heard. Also according to the same "lore of history", at best 50% reliable :) ... Beethoven wrote 18 or so versions of his 5th symphony's 1st movement. He wrote and re-wrote constantly. Though he was actually luckier than we are today ... he had all the previously handwritten copies right there. We have to struggle with lost 0101010011100001...... :) If it is that important to retain every small change from the current version, just "Save As" with new date, time, and measure numbers as part of the original file name. Storage is dirt cheap these days.
Or ... think it out in advance and put it down as you hear it. It is good training.

I am a 75 years old and a recently retired business owner. Have been playing piano professionally since I was 15. Though it brought in a respectable income while in school ... (better that washing dishes at the high school/university cafeteria) ... and later as family fun money in addition to my day job, at 70 I had enough gigging. I still practice and play the piano daily because music is food for my "soul", for lack of better word.
Aren't we all involved with music for that same reason?
Just have fun and enjoy the ride!!!

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