In this toolffx.tools.GUIAutomationRecorder V1.10I write lot of automation. Now it turns out that Renoise seems to crash while undo/redo action (assuming a bug in the undo history) and also splits the writing actions into several steps.
Can I somehow join multiple automation writing steps into one, defined undo action? Or can I even prevent a function to trigger undo at all?
Thanks for ideas or tips!
Now it turns out that Renoise seems to crash while undo/redo action
Crash? That’s serious stuff, should be reported as a bug then.
Generally speaking, the API should never be able to bring down Renoise…
Edit: oh, you already did. Cool.
And no, you can’t avoid undo steps if you’re changing the song/document. Skipping just a single undo step in history will corrupt the document state. That’s simply a no-go.
I remember some talk about whether an undo step could be hidden from the user …I think is the only realistic way to implement such a thing.
As for joining undo steps, that would only work if you’re somehow ‘detaching’ the data you’re working on, for the same reason as above (what happens if some other tool modifies the data you have just modified?). This ‘detach’ approach is used when generating data for the sample buffer.
And no, you can’t avoid undo steps if you’re changing the song/document. Skipping just a single undo step in history will corrupt the document state. That’s simply a no-go.
I remember some talk about whether an undo step could be hidden from the user …I think is the only realistic way to implement such a thing.
Ok, I now understand this again. Like if add-automation was one time prevented, and later the automation was manually edited and then undo’ed, it would be undo on a wrong data base…
But is a “join_undo()” also a no-go? Like called in a method, it would join the current/next undo step with the last one in history…
But is a “join_undo()” also a no-go?
I tried to explain in my previous answer - you’ll still be able to corrupt things if something else had made changes in the meantime.
So the only solution is to work on detached data - not modifying the document until the very end.
I tried to explain in my previous answer - you’ll still be able to corrupt things if something else had made changes in the meantime.
So the only solution is to work on detached data - not modifying the document until the very end.
Sorry, but still don’t get what speaks against a joining… In the API. If there were one undo step instead multiple, bringing the same history result, why is it corrupting anything then? Joining for the time of the function call, joining with the last history step, what can interfere here then?
Danoise, danoise!
Like: add point, join last history step,add point, join last history step,add point, join last history step,add point, join last history step,add point, join last history step,add point, join last history step…
and so on!