History list
Musescore clearly has some form of history list, as it's possible to revert changes and do this repeatedly, or redo the changes. Some other tools I use, such as photo editing tools have similar features, but they also have a list of changes, so one can identify which changes have been made, and perhaps when. In the case of Musescore something like this might be very useful, as sometimes one makes changes to try things out, but then wants to roll them back. An alternative way is to save each score before making any changes, but then one might end up with many scores, most of which are not really needed. An even better approach would be to have a history list with some sorts of markers, indicating points at which a sequence of changes was initiated, then simply rewind back to those history marker points for each change which is not adopted.
This kind of thing wouldn't solve all problems, but would go part of the way towards making MusesScore even more usable than it currently is.
Comments
The "undo stack" is only active during a single session, once you closed a score it is lost, and no history is kept.
If you want a change histore to be kept, use something like git (and probably better use the mscx format) or, as you just mentioned yourself, store multiple versions.
In reply to The "undo stack" is only… by Jojo-Schmitz
That’s not what the request was about.
Some software makes the undo stack visible, so you can see what changed where and why (by which trigger, e.g. keypress, plugin, etc.) and you can often do undo and redo by selecting a certain point in the undo stack list instead of having to press/click the undo/redo key/button/menu entry multiple times.
This would be nice, especially if forked stacks are supported later (undo some, then try something else with the option to go back to the place you started).
In reply to That’s not what the request… by mirabilos
Hmm, OK, guess I haven't seen such a software yet.
In reply to Hmm, OK, guess I haven't… by Jojo-Schmitz
Offhand I can name GIMP:
Pretty sure there are quite some others. Maybe Inkscape, but I can’t be bothered right now ☻
In reply to Offhand I can name GIMP: … by mirabilos
Definitely showing the undo stack and letting you quickly choose how far to go back is pretty common, especially in the image editing world. Being able to then execute those commands individually, so you could undo one command within the stack without undoing everything that came after - that's a lot trickier as other commands may well have depended on the results of that. But here, again in the image editing world especially, it's not uncommon to be able to separate work into "layers" or otherwise retain individual control.
I could imagine some DAW software providing a similar model but I have much less experience in that area.
In reply to Definitely showing the undo… by Marc Sabatella
I'd be in favor of just the stack visualization without the individual command functionality. It's often during hitting Undo/Redo shortcuts that I partially wonder how far back I went and whether I didn't undo something too much.
In reply to I'd be in favor of just the… by jeetee
Affinity Photo is another photo editing tool which has a kind of history for previous edits. One issue is whether you count "undo" as an edit command to be added to a history list or not. Usually that's not the case, so performing a sequence of "undo"s does lose any good ideas which may have been recently developed. For example, one might have Edit Sequence A then Edit Sequence B then Edit Sequence C, then decide one really wanted to lose the B sequence to produce the effect of Edit Sequence A then Edit Sequence C. This would involve backing over the B and C sequences, then redoing (from scratch?) the C sequence.
The structure one really wants is not just one stack, but two, with the option of inserting or deleting elements from the middle of the structure. However, even the stack history list would be better than nothing.
In reply to Affinity Photo is another… by dave2020X
The counter-argument there is that this type of changes is much more often less sensical in music notation.
Say my stack is something like:
And you choose to only "undo" the edit that removed m5. Should the select m4-6 now be altered to become m4-7 (same musical boundary) or now be applied to the "new" m4-6 range?
Both options are equally unaware of the intent of such an edit and likely the wrong choice.
However if all you're allowed to indicate is to "roll back" the stack to a given action, then the implementation is rather trivial and the expected end result will always be way more predictable.
In reply to The counter-argument there… by jeetee
Let's forget about funny selection of pick and choose in undo/redo list, simply displaying them would be a great step forward.
Next easy thing to add to that display is "undo up to" and "redo up to" (the easy way: only "up to" option, no "skipping step" feature).
Suppose you have typed many [ALT]+{ to change stretch.
"Undo up to" would allow you to undo all of them in one shot, without having to press [CTRL]+Z until you see MuseScore undoing something else where you know you have reached the end of [ALT]+{ end you must type [CTRL]+Y once.
Other indirect advantage of displaying the undo list: sometimes you try an action and it is unclear if MuseScore did it or not, e.g. for some actions where selecting a single note is enough from the menu but requires a "correct" measure selection from the palette. The change in the undo list would make clear if the action was taken or not.
Or when you double click a palette item and add 2 of them instead of 1: again that would appear clearly in the undo list
Really that undo (and redo) list is a must.
In reply to Definitely showing the undo… by Marc Sabatella
Marc wrote>> showing the undo stack ["lets] you quickly choose how far to go back is pretty common, especially in the image editing world.
Indeed. I've seen an undo stack in Adobe Lightroom.
In reply to Definitely showing the undo… by Marc Sabatella
Another issue is the matter that in order to undo a particular edit via the undo feature, you must undo every edit between your current and target edits. A visible undo history could help the user to choose whether it is better to step all the way back to the undo point, or simply re-do the edit.
Still another issue is that some operations as far as I know still do not mark the score as "dirty" or respond to undo commands. (Mixer movements, synthesizer settings, etc.) They ARE saved with the score, but appear to be actions outside of the undo stack.
Undo will often jump to the score page on which the edit lies, but will not necessarily show what has been undone. Other times, for example of when you've been editing spacing or layout, the score position does not change upon undo, and it becomes a matter of watching to see what changes on the screen when you hit undo, and hoping that you've hit the right number of clicks.
This has been on my wish list for quite some time now. The undo feature should be able to help the user along by showing where in the list of edits a particular operation took place. As it is, we resort to clicking undo (or CTRL-Z) until we see the result we want.
The undo feature on many text editors will break down the steps to anything from single key-strokes, through words, sentences, and even paragraphs. This would be analogous to combining a dozen or so incremental clicks in the inspector to one single operation. That would be a tremendous time-saver in MuseScore.
In reply to This has been on my wish… by toffle
One problem with CTRL-Z is knowing when to stop going backwards. I think MS doesn't save the history when the score is saved, so one option is to periodically save the score when one is reasonably satisfied. However, there are problems if MS crashes, which it does sometimes, then one doesn't know exactly which edits need to be redone or corrected.
That's why I think a history list would be a step in the right direction.
Someone else had an idea of something more like a wiki - which is also a good idea, but might be just too difficult to implement and manage. The idea there is that there would be a complete history right from the very first score onwards, and if each version had its own history list that could be very powerful, but it could also be very confusing in the "wrong" hands.
In reply to One problem with CTRL-Z is… by dave2020X
File versioning is something entirely different from showing the active undoredo stack, a thing that only exist during a session.
So no, saving the file inbetween doesn't "reset" that stack. Saving, closing and then reopening would. If you want persistent file versioning, then use a tool for that job, such as a local git repository. I don't think it should be MuseScore's job to also be a file versioning system on top of a notation editor.
In reply to File versioning is something… by jeetee
I'm not sure that I quite understand what you are trying to say here.
As a quick check I made some changes to an active score on my desktop, then saved and closed the file.
On re-opening there is no active undo list - so no active history list. If a history list feature were added it might be helpful to have the history list saved on save and close - or at least it could be an option.
Re versioning, I still have an open mind on that one. What would be very useful would be some form of note (as in paper notes) addition to each score, so that the author or editor could remind him or herself what each version currently contains. At the moment I save multiple versions of pieces I'm working on, and I try out different effects in each. The pieces are linked conceptually by file names. Thus I might have a file with a wind quintet setting, a file with a solo instrument setting, a file with a percussion ensemble, or a file with brass or strings, or even an electronic synthesiser version etc. I might want to have notes on each - saying which of each actually "works" for me. One could imagine a concept such as a "file cluster" of MS files which are related - and that would be relatively easy to do I think, as it seems that the MS files are actually quite compact. Things would get much harder if sound files were required for each element in such a cluster, though they're not normally too difficult to generate again, so the basic "cluster" idea would work.
I really would like to be able to add notes (text notes) as text into MS files. Trying to use other text forms (e.g. system text or stave text, or rehearsal marks) is just clunky, and limited in application.
Also, such additional notes could work well in a collaborative environment - and not only serve as reminders for the original author/composer/editor - but also as a means of communicating between different participating users of any music text.
In reply to I'm not sure that I quite… by dave2020X
Huh, saving the undo list to the file is not something I’ve ever seen anywhere. I’m not sure I want that, too… I do version my scores (as
.mscx) in git. I’m putting notes into a TODO file next to them if needed… or even into the commit messages.You can add text notes to a MuseScore file by adding a frame (horizontal or vertical) and putting text in there. Or just add another text to the frame that already exists with the title. Or put it into header/footer (the header is by default empty).
In reply to This has been on my wish… by toffle
In most software I tend to press ^Z one time too many, then redo, in order to be sure I’m precisely where I want.
In MuseScore, the undo sometimes happens elsewhere in the document than where the cursor is, so that’s even harder…
In reply to In most software I tend to… by mirabilos
Exactly. It becomes very hard to spot the precise point to stop doing the undo. If one anticipates that one might want to create a sequence which might be rolled back, then it is possible to deliberately put a pattern - for example a particular note or sequence of notes into one staff as a form of marker, so that one can roll back to that point, and then remove the marker sequence. However that only works if one is expecting that some edits may be the subject of a roll back. Quite often one doesn't know. There are various other ways to resolve this problem. One way is to have some other marker (not actually affecting the scripted music text) which is embedded into the history list which is created by specific user action, and another is to time stamp each change, so that it would be possible to get close to the exact point to roll back to. These approaches could go some way towards improving the rewind operations, but might not be completely unambiguous.