Battery 3 desperately needs an undo option..

Discussion in 'Feature Suggestions' started by touched1, Sep 26, 2007.

Thread Status:
Not open for further replies.
  1. touched1

    touched1 NI Product Owner

    Messages:
    153
    Seriously....
    How can you make an app like this with no undo option?

    Please add it, and fast.

    Thanks,
     
  2. touched1

    touched1 NI Product Owner

    Messages:
    153
    I mean this now more than ever.
    I just spent twenty minutes balancing levels on a kit, hit a wrong button (I have no idea which one) and now my cells are missing or scrambled.

    My fault for not saving first? You bet. But something as simple as an "undo last action" option would save me a half hour of work right about now.

    UNDO OPTION PLEASE!
     
  3. brettw

    brettw Forum Member

    Messages:
    59
  4. touched1

    touched1 NI Product Owner

    Messages:
    153
    I can not yell loud enough for this...
     
  5. samplerbill

    samplerbill NI Product Owner

    Messages:
    76
    Its been said before and well worth repeating. Even some of the cheapest recording programs,even some freeware, has an undo function. Most professional sound software can undo multiple steps.
     
  6. Steve H

    Steve H New Member

    Messages:
    12
    Just don't make any mistakes, and you'll be OK!
     
  7. Woodman2

    Woodman2 NI Product Owner

    Messages:
    50
    Undo-function would be very nice indeed!
     
  8. WillBarnett

    WillBarnett Forum Member

    Messages:
    339
    Yeah I 10th that. Desperately needs that function. Too many times Ive accidentally done something and lots loads of edits.
     
  9. Kait

    Kait New Member

    Messages:
    3
    both hands up.
     
  10. soulfry

    soulfry New Member

    Messages:
    8
    Agreed -- the software definitely needs an undo to support risk-free experimentation, and to help out newbies just learning their way around the interface. All too often you can do something with unintended consequences and not know what you just lost.
     
  11. IlMolto

    IlMolto NI Product Owner

    Messages:
    234
    Definately need an undo option
     
  12. macik

    macik NI Product Owner

    Messages:
    14
    I would appreciate it too.
     
  13. Orbit-50

    Orbit-50 NI Product Owner

    Messages:
    115
    Undo would be appreciated. - Orbit-50
     
  14. jamester

    jamester NI Product Owner

    Messages:
    95
    For the love of all things holy give us a damn Undo button!

    How many times does this need to be asked for? C'mon....

    Picture this:

    You've got your kit perfect, which took a whole lot of time. Now you go to load a loop, and only want it on one cell for triggering. However you don't realize that Battery is still set to load all slices to individual pads from your last session. In one click of the mouse you have royally F-ed up your entire kit, and now have to spend a LOT of time getting back to where you were - killing all creative sponteneity and sense of fun in the process.

    The simple click of an Undo button would have made things all better. Give us a freakin' Undo button!
     
  15. IlMolto

    IlMolto NI Product Owner

    Messages:
    234
    Damn that would suck
     
  16. soulfry

    soulfry New Member

    Messages:
    8
  17. Thomas @ NI

    Thomas @ NI Administrator NI Team

    Messages:
    1,576
    I already posted this in another thread a while back: Unfortunately it is highly unlikely that an Undo function will ever be added to Battery 3. That is because some of its features are based on KSP scripting, which does not go well together with undo functionality at all.

    Our developers have tried to solve this, but the combination of scripting and undo created substantial performance issues so the implementation is not practical.

    Regards, Thomas
     
  18. jersey8five6

    jersey8five6 New Member

    Messages:
    14
    i really don't understand why it doesn't have it in the first place

    ok never mind

    but tell them to keep trying! lol
     
  19. soulfry

    soulfry New Member

    Messages:
    8
    Thomas -

    While it may be inconvenient to code this functionality, it is even more inconvenient for the 100s or 1000s of users who live with the lack of this functionality. In fact, it is easy to make the argument that the costs you describe for implementing undo (developer time, potential application performance hits) are a *much* lower cost than the costs your 100s/1000s of users absorb when they expend significant time working with the tool, only to have that work mistakenly erased by an errant action. Furthermore, the workarounds we must adopt to compensate for the lack of undo, such as frequently saving kits, are likely more time consuming and more of a "performance hit" than the performance problems you would encounter if your team implemented undo. In short, we as users, have our performance impacted by the lack of undo in three undesirable ways: 1), when we lose work through an errant operation, 2), when we need to remember to repeatedly save our kits in case we make a mistake, which causes us to shift the focus of our attention off the problem of making music, and 3), when we must carefully consider the state of the interface prior to making an action, just to make sure that that action will not irreversibly destroy our work. The computer should be doing this work, not us.

    That NI made certain architectural decisions that make it difficult to implement undo is unfortunate and somewhat surprising for a commercial software company. But to not address fundamental usability flaws is arguably the worse offense. That said, it is obviously not impossible to address this problem, because we as users already address it through workarounds -- frequently saving our kits and saving copies of our kits. I find it difficult to believe that a rudimentary undo could not be developed by mimicking these very actions, saving the same data that is saved to file, but to memory (or to a temporary file). I also find it difficult to believe that a basic "every n-minute" back-up scheme could not be implemented to partially address this problem so that we can at least open up a recent version of the kit.

    Michael Terry
     
  20. soulfry

    soulfry New Member

    Messages:
    8
    To put some numbers behind my comments above, I took a look at the size of one of my custom kits. It is 61KB on disk. 61KB is a trivial amount of information and could easily be contained within a simple linked list or fixed-size array that records the kit's entire state over the last n actions. That is, if, after every significant action, you store in RAM a copy of the kit after each action (where the information stored is simply the exact same data that is saved on disk -- patches, not samples), you are taking up only 61KB for each action performed. Let's say you don't want to take away too much RAM -- a valid concern. In this scenario, even if you store just the last 10 actions, you are still taking up less than 1MB of RAM (610KB, to be exact).

    But to be fair, we need to consider the time it takes to both store and restore kits for this very simple undo scheme. It would be unacceptable if saving a copy of the entire kit took 1 second or more, because that would interrupt the user's workflow. So I tested this out. On my old 1.5GHz Centrino, "Save As..." happens in less than a second. In fact, it's hard for me to discern when it actually completes. And this is saving a copy to the hard disk, a storage medium orders of magnitude slower than saving to RAM.

    What about restoring a kit? Here we see a performance hit. Initial loads of a kit are slow. But when I reload a kit, it takes ~1 second long to reload the kit. However, much of this load time is due to the reloading of all the *samples*, not the kit-specific data. Thus, the restore time could obviously be significantly faster if samples were not reloaded. Even so, I would gladly wait 1 second or more to restore minutes or hours worth of work on a kit.

    Looking at the time it takes to perform the manual equivalent of undo -- saving a copy of the kit to disk (<1 second) and restoring the copy from disk (~1 second) -- it is hard for me to imagine where the performance hits could actually come into play for implementing undo.

    Perhaps the complications arise in actually hooking into the code to implement undo. For example, it may be the case that your architecture makes it difficult to add code to *all* the places where changes can occur in a kit: Rearranging cells, naming cells, changing cell parameters, etc. I say that it "may be" difficult to insert code to call a simple "save kit" routine as outlined above, but it is not likely as difficult for the developers as it is tedious. That said, among the types of changes one could make to a kit, there are some changes where the lack of undo is more costly and more difficult to recover from. Laying out an entire kit and having that arrangement mistakenly wiped by an errant action is more costly than modifying a sample's loop points. In the latter case, I can easily forward-correct my error by readjusting the sample's loop points. In the former case, I need to manually lay out my samples again, recreating my decision making process. This is a big cost and is also rather discouraging. Implementing rudimentary undo for just the costliest mistakes would be a big win by itself.

    I hope you will seriously consider investing the resources to address this problem, rather than passing on to your users the costs associated with the absence of this feature.

    Michael
     
Thread Status:
Not open for further replies.