On 13/06/12 15:03, Atte André Jensen wrote:
> Bit me too. There's probably a real good explanation why you can't undo fader
define "a fader move" ... how far do you go back ... especially if you are
moving the faders via midi, more than one at the same time (actually those moves
would be interlaced I guess), and perhaps with a bit of noise from the
interface, and possibly other controls being operated while the faders are moving??
Do you go back to the last time all faders were still? how long between steps is
a "still" point in time? (going back 1 step of the last fade probably isn't very
useful and would make the undo queue unusable for anything else!) defining and
recalling the "beginning" of a move is a bit tricky ... some kind of animated
rewind of actions may be cool, but not so easy to implement. Otherwise do you
expect to take a full snapshot every time the faders start to move after being
still, so every change made since that time is undone - going back to the state
pre-move, or do you expect that the faders are returned to their last "still"
state but all other changes made since then are retained?
Just pointing out that as a feature there would be many things to decide, and
maintaining such an undo queue might take more cpu than you really want to use
for making a potential undo possible ... so perhaps manually taking snapshots at
relevant times is a sensible approach?
Linux-audio-user mailing list