undo/redo system

[Nubeat7]

a simple undo /redo system, you can choose how many undos are possible..

it is only for one parameter! so if you want to do it for more parameters, you also need to indentify the parameter via its preset name or a parameter id ..

[tester]

I would not use preset system, but something based on that ones.

[Nubeat7]

thanks for this example tester, just one question, should there be a limit of undos? specially if i use strings, because using the stack prim means using the ram stack or? and when playing around 1 hour it really could fill up the stack when no limit...

[tester]

I guess the reasonable limit would be:

- around 16000 operations, because a lot of modules play around such size of max array

- 50-2000 in multi-multi-setup in very continuous use (tens of arrays used at once), because in some cases (array builder/splitterer) it is suggested to use not larger arrays that way (refreshing at each change); with my experiments with preset manager and string conversions - I would agree on that.

Each change of a single value would refresh the whole array.

In other words - I think you don't have to worry about that part too much.

1) Make a test design in which you feed the design with long arrays and see how it behaves.
2) Check how many clicks you can generalte manually within 1-3 hours.
Such sort of tests should help.

/edit:
Such sort of tests for example. If you use strings, you can create array of words, driven by such generator. You can add tick100 with randomizer on such array and trig counter, to see when it starts to slow down. And so on.

[Nubeat7]

i like this technik with the stacks but how could i limit the undos to 10 or 100 steps?

[tester]

Why limit?

[Nubeat7]

because i dont want to fill up the stack with no border, thats why i asked if it fills up the ram stack (it does or?) and i think 100 are enough, i think filling up an array endless is no good style and could end up in unwanted effects...

[tester]

Stack/queue sends outs the array size too. You could use it as a switch basis to pass values through undoredo or without it. But this will produce funny situation, because if you exceed the limit, then your final undo/redo step will be confusing to the user.

You are not connecting it in continuous automation-like style to knobs (use timer delay to block when knob is on the move).

I would check first what are the working borders of these queue/stack modules. Something tells me that these fellows may be surprising.

BTW, they are being reset per each session/restart of the plugin.

[Nubeat7]

Stack/queue sends outs the array size too. You could use it as a switch basis to pass values through undoredo or without it. But this will produce funny situation, because if you exceed the limit, then your final undo/redo step will be confusing to the user.

thats why i `m using the queue because after the given size is reached i can pop out the oldest entry always when a new one is pushed in, but the redos are still handled wrong, what is done in a nice way with the stack...

You are not connecting it in continuous automation-like style to knobs (use timer delay to block when knob is on the move).

i wouldn`t activate while automation anyway... and thats just the enviroment around it, before i need a working solution

[Nubeat7]

after putting testers example into ruby it was easy to limit the undo steps..

latest version in the first post