Separate Undo Levels Please

Perhaps this is just my odd sense of “good ui” kicking in, but it seems to me that undo levels should be dependent upon which module of an application you’re using… instead of being applied everywhere.

Common scenario:

  • I edit a sample/instrument/preset
  • I lay down some new notes… change the melody… or do something else to the pattern in order to test the new instrument settings
  • I listen, and either decide I don’t like the new instrument settings, or wonder what the new edit would sound like with the old version… so I go to the instrument editor/sample editor/whatever and press ctrl+z …
  • No change happens… I get frustrated with the sample editor and press ctrl+z a few more times
  • My instrument finally reverts back to how it should be
  • Listen to the pattern… WHAT!!! WHERE’D MY BEAUTIFUL MELODY GO???
  • At this point, I’m not sure whether to shoot someone, or uninstall Renoise permanently… cough
  • I go to my therapist, and pay $200/h to rant about how my life as an artist is never going to come to fruition because of all these damned creative roadblocks
  • A month later, I’m jailed for stalking Taktik, trying to get my fixes added into the next build
  • I die in a lunchtime knife fight when some biker yells out “MADTRACKER RULES, RENOISE DROOLS!!!”

So you see, it’s imperative to my well being that these undo levels be fixed, lest I fall into the hands of chaos and ultimately, death.

[edit]Also, it would be nice if undo levels could be on a per-selected-dsp basis insread of dsp-chain-wide[/edit]

At this point you go and redo all levels until your beautiful melody is restored… you copy your melody into the clipboard and then undo back to the point where your instrument should be, then paste back your beautiful melody.
I know it is a very ackward method, but that works.
Taktik explained in an older yet similar topic (the 1.8 beta/final stage) that undo levels are hard to pinpoint to specific areas… some relationships like parameter changes of a VST plugin and then deleting the plugin from the rack has to remain in that particular order… you probably don’t want Renoise to crash just because you decide to undo parameter changes on a vst plugin but you skipped the plugin deletion step from the undo query.
The system at this moment roughly works similar to other applications that have such undo options (Like photoshop). The only thing that lacks is a sort of log-list where you have an overview of what changes you made. Except for the last action to be undone or next action to be redone in the “edit” menu on top that reveals it.

That’s it, I’m switching to eJay leaves

ctrl y

I don’t decide if something is done about this issue, i only gave you the answer i got when i pinpointed your problem during the alpha stages of 1.8 as i predicted to be complained about when 1.8 would be released.

I agree that undo actions in the sample editor should not be mixed with pattern editor actions and actions of other areas. But the whole undo as it has been written (and i understoodso far from Taktik) now is soaked in the whole application, so changing this would mean massive work.

Sorry… I forgot to use the [joke] tags… I realize such a thing may require a pain in the ass… but that doesn’t mean I can’t request it :P

Unfortunately, from various posts I’ve read, it seems like there are quite a few things in Renoise which have been written in such a way that they’re hard to change, like this, effect routing, and certain keyboard mappings, which kinda strikes me as tragic, because it implies that the code isn’t as modular as it could be… modularity being a very (perhaps the most) important design principle that allows large scale projects like Renoise to evolve. I sincerely hope that Renoise’s codebase is becoming more modular, MVC and OOPwise as time goes on… I would hate to see it go stale as a result of an avoidable scalability disaster.

Don’t get me wrong… following these paradigms strictly to the letter would probably cause mass suicide among the world’s programmers… but keeping them in mind at all times when developing classes can at least make you think about potential problems before you go hardcoding something that will take even longer to fix down the road. I’m not a codely saint by any means, but I definitely try to at least think in terms of MVC and kosher OOP when I’m developing applications. The other thing is, when reviewing old code, it’s best to try to reevaluate it while you have the chance, keeping the project’s potential future objectives in mind. I’m sure Taktik does all of these things, I couldn’t see him not doing them, but if he isn’t, man I’d hate to be in his shoes when trying to make any sort of large change to the software. But yes, I do trust Taktik and the rest of the team are making the right decisions in regards to Renoise… the proof is in the pudding. I just have these odd worries sometimes :P

This would be possible with the current code base - don’t worry. Renoise is not written in assembler or pascal. The problem is that your approach adds dependencies as you have to take care of whats already undone/redone in which (user visible) component and whats not if we want to keep the global undo as well. So the current way is the easy, stupid independent OOP way.

Anyway, this would be useful, yes, but also from a user point of view this is also problematic. The current undo has two actions: undo/redo, your way would need a complex undo/redo manager. Just because someone needed this option once, this doesn’t mean that this option should be there to confuse everyone else. Thats what we should discuss, not the code base:
Lets simply keep the ideas and suggestions forum a user forum, not a dev forum. The code is my problem - if somethings hard to implement or not is my problem. You all should not waste a second thinking about this. Everything is possible code wise. You job is to make suggestions that make sense form a user point of view…

Remind me of this if I ever say again “that would be hard to code”.

Agree. Always wanted this.
Ultimately have both. ctrl z/y for global, and for instance shift+ctrl+z/y for local.
Especially the samples can be a pain. If we ever get an arranger or audio tracks etc, then this can easily be a nightmare to only have global undoes.

For other part of Renoise this might not be so important? Like automation etc… dunno.
Now I always have the habit of making snapshots of everything (manually backup things I think I might change later).
But even just splitting this into 2-3 parts would help a lot.

You can turn the undo off in the sample editor, because it can be quite time consuming with very large samples. But when it’s on, it is still a global undo.

Complex undo/redo manager?
What about a dialog-frame that shows all undo/redo actions for the currently focussed area (with a dropdownlist on top where you can hard-select a list from different area)?
You can either hide or display the dialog and for those that want to work intuitively, they hide it and if one gets lost, they can pop up this list to check it out.
Seems a good hybrid solution to me.

I don’t want much, just

  • Save undo history with song, or in a sidecar file/folder which renoise keeps invisible when browsing in Disk Op. (ummm… I mean Disk Browser ;))
  • Set snapshots like Photoshop ones (but not necessarily “history” list)
  • Undo recording overwrite
  • Smarter sample undo ala Adobe Audition: editing a long vocal in Renoise should not take many seconds per operation just because the Undo decided to buffer the whole sample instead of just the changed bit(s)

if (suggestions.implemented()) marty.dopamine++;

Newschool design methodologies dictate that you shouldn’t be accessing dopamine directly, instead, you should do the following:

if (suggestions.implemented()) marty.happy++;

…which in turn will increment the dopamine internally. This prevents end users of the “marty” object (presumeable of the Person class?) from screwing up the dopamine calculations, and also allows the happy property to do other things, for example, triggering the view update method, making marty smile.

I simply meant allowing ctrl+z to undo only what’s been done most recently with whatever is currently in focus, that’s all… From a user POV, I wouldn’t want to add extra confusion at all, and a huge undo manager would definitely add confusion. I would definitely also want an “action history” panel’s timeline to be global.

Sorry, I’m a developer… I can’t help but think in such a manner ;) … and you’re right, this is a user forum… but I’ve yet to get access to that lovely “feature development” forum that I don’t see anymore… quite possibly because nobody likes my ideas ^_^ … should I take a hint? :lol:

lmao :P

Its not that easy IMHO. One example: Lets say the instrument box has the focus, then you would assume that the local undo/redo feature undo/redos instrument related changes only (changes within any of the instruments + changes in the instrument list itself), right? Thats at least what I would expect.

You only wanted to undo changes in a selected instrument, so using the keyboard focus for this wont work for your case. I dont think that we can solve all the wishes without a complex manager thing.
Also no one on earth except me and the alpha testers team understands the keyboard focus thing, so its really not suitable to be the source of a new even more complex feature.

But we could at least only make the sample editors undo/redo function local. Thats where its needed most. There it would always be “local”, with no extra shortcuts or manager or whatever.

I love to screw up my dopamine calculations

I’m like :( :angry: :unsure: :huh: but I’m rapt in ecstacy :ᅠ)

Any news on this ?

Would be great to keep the global “undo/redo” in the edit menu + have the possibility to undo events locally (right-click on an area, “undo/redo” appears in the menu list)

is it just me or would it be simply to separate the undo-actions by the same categories as the “Key” area in the preferences.