Pressing a button in my module changes the values of multiple knobs. But pressing Ctrl-Z afterwards fails to recover the previous state. I assume I miss a step adding values to a history list for undo.
Is this the history I had to study? Is there any module with a simple and clean implementation you could recommend?
For me it’d be much easier to learn about the usage from some existing code.
The most important thing to remember is that you mustn’t try to store a reference to your module or control in your history object. Instead you can store the module id and then find the module via the id when you need to undo/redo.
The reason is that someone might turn your knob, then delete the module, then undo twice. Your module reference would be invalid by the time you need to action your undo.
Thanks for posting. I hadn’t considered undo, looks like my Polygene randomize channel button needs the special treatment.
Undo doesn’t undo context menu changes either? Is that something module developers should be handling, or a VCV ‘feature’? I can’t find any module that can undo a context menu change.
The Seq++ stuff might need looking at again. Undoing Rec and Scroll works, but Run doesn’t. Whilst VCV does know about ‘insert note’ actually running undo doesn’t update the display. I’ll file a bug - I’m using latest source builds for everything so could be a regression.
Just make your context menu entry a parameter, then undo works out of the box and the state also get saved out of the box (no noodling with json needed). This only works for numeric values.
I would suspect there are a lot of modules that don’t have proper undo. As @Ahornberg points out, the only thing you get for free is parameter changes. Which is enough for a majority of module, but there are a bunch that require more.
I remember @clone45 mentioned that Voxglitch modules don’t use parameters. Looks like undo doesn’t work on them.
no, the stuff in VCV is in the param widget class (I now see). Which is probably good - I don’t think you would want a CV change to be “undoable” - it wouldn’t even really make sense. But turning a knob, adding/removing a module, patching… Those things are undoable.
Exactly. The only reason I ask is that there is still a bug in Rack (I believe) that may involve, undo history, autosave, selection files, editing and “reset” in some very deep manner that eludes me as well as a couple of others who have dug into this.
This is an important question for me. If I work on a single patch for quite a while through multiple actions, does the undo history just grow larger and larger? There is some circumstantial evidence that this is the case. What happens if the user reloads the current patch? Does this clear the history.
I’m also concerned that there is also circumstantial evidence that history related crashes may be aggravated (or caused) by some plugins or modules. Is everyone who is developing module undo management doing so correctly?
I know this is off-topic, but, I think these are valid questions.
How is the undo history maintained? Is it part of the patch file, or is it a json file and if so, at what level? Or is it something else entirely?
I am very concerned about “complex actions” history, such as with selection files as well as select and copy or duplicate for multiple modules and cables, as well as deletes.