Hi,
my send-to/from tool is a bit broken since renoise 3.1, because 3.1 now also undo buffers track color changes. The script uses a color flashing.
So I would like to request a feature that you can disable undo completely for all actions done by a script.
Is there currently a way to disable undo while color change?
Second request would be those two lua API functions:
Disable_Undo()
Enable_Undo()
So just before track color change and right after, I can place those two calls.
Please help.
Or is this a bug that was introduced in 3.1?
Taktik, please have a short look at this.
Install the tool: https://forum.renoise.com/t/new-tool-jump-to-from-send/34051
Bind the two keys. Now jump from a track to a send. The undo buffer is now flooded with all color fading colors.
What about a Api function " Disable_Undo_once ". , so only for the next operation, there will be no undo written? It’s also a problem in other tools, too.
Taktik, please have a short look at this.
What about a Api function " Disable_Undo_once ". , so only for the next operation, there will be no undo written?
Interesting idea. Having this as a one-time flag would avoid an otherwise major weakness.
I mean, the ability to disable undo entirely from Lua tools would be kind of ‘dangerous’, especially if a tool was somehow faulty…then undo would suddenly have been disabled for the remainder of your Renoise session, not good…
I mean, the ability to disable undo entirely from Lua tools would be kind of ‘dangerous’, especially if a tool was somehow faulty…then undo would suddenly have been disabled for the remainder of your Renoise session, not good…
Disabling undo will also quite easily break down the whole undo/redo logic and thus Renoise. If you for example suppress undo for the insertion of a track, but not for something else that you later on are doing with this track applying undo/redo will sooner or later crash.
So no, we can’t add that and have to solve this differently.
When the tool changes track colors, this always should have been in the undo/redo chains. Not sure why it wasn’t in 3.0.
Hey Taktik ,
And what about a undo “ID” , so in my case, I would set "set_undo_id_for_next_action(“crazy color flash”) " and for any next color change/exact same action in the tool, the previous undo with id “crazy color flash” in undo queue was deleted?
Would that in any warm harm stability?
Ok above makes no sense.
Can we revert old behavior then? Must be a color change really undoable, is this deluxe paint?
So, only “workaround” now is to completely go without crazy color fx?
Please, any help would be appreciated…!
EDIT: maybe it would be possible to put manual color changes to undo history, but not any color change made from LUA?
I second this. Disabling undo for anything the tool does internally would be great.
NB. I am syncing my track list to the instrument list, which is easy enough with some notifiers, until pressing ctrl-z and everything breaks due to a state that “isn’t expected and can’t be handled”. Upon a track insertion and subsequent undo, tracks_observable will get banged as well as undoing what the tool did previously - now deleting two tracks. It seems to enforce some hardcore stateless programming handling such cases… and I admit defeated.
This is still true:
Also, what you’d need is a flag to check if the notifier is called from an undo/redo action?
Yes, that’s a very good idea! Maybe.
Edit:
Then it can be handled as a special case and circumvent any unwanted effects. I’m sure it can still be broken though (what happens if you have two track insertions from another tool, that get coupled as one undo event. I don’t know if this can happen, but things like that might still break stuff). Maybe the conceptually sane approach is a more granular undo-buffer, that more aggressively decouples things that are inside notifiers when it comes to undo events…
Or maybe the event should say if it was triggered by a native shortcut (such as ctrl-z triggering a track insertion event) or from inside the tool…