Can OSARA offer users a choice to close parameter dialogs, discarding changes made?

[ScottChesworth]

I've received requests for this UX during tutoring sessions and seems desirable here:

1. OSARA would store parameters when our dialogs open, doing some magical stuff to store those in RAM temporarily.
2. Users make changes as they can now.
3. Instead of a Close button, there would be OK and Cancel. Hitting Enter would click OK, hitting Escape would Cancel.
4. If canceled, parameters would be reset to what they were when the dialog was last opened, discarding changes made since.

I dimly recall this being discussed in the past, and back then I think the answer was sighted folks don't have this functionality provided by REAPER. However, many effect/instrument developers do provide users with a fast way to revert to the last preset/patch they loaded, or they provide a way to A-B changes. Given how there are so many effects/instruments where we don't have easy access to features like that in their native UIs, I'm hoping this can get a second round of consideration?

I think this could address a couple of specific pain points that I've seen plenty of times over:

1. Exploring virtual instruments where parameters are either poorly labelled or finicky to use with full range sliders. There have been plenty of times where I or someone I've been teaching has gotten pretty close to dialing in what we want, but a single trip into the FX parameters attempting to make a specific change can derail all the prior progress.
2. When new users aren't fast at navigating yet, this could lessen the time hit of them having to remove and reload an effect/instrument.

I foresee concerns from existing users who might hit Escape out of habit, losing their changes. Figured we could call REAPER's stock Yes/No buttons prompt to protect people from losing work they did want to keep. Just an extra safety buffer initially, might not stay around forever.

How complex would this be to implement?

[ScottChesworth]

Alternative/possibly easier idea: maybe we could wrap each open/close of the parameters dialogs in an undo block? That way there's no GUI work to do, but it's still possible to revert the last batch of changes in one shot if needed?

[jcsteh]

back then I think the answer was sighted folks don't have this functionality provided by REAPER.

I don't recall saying that, but if I did (which I'm not at all ruling out), it certainly wasn't the primary reason.

The fundamental challenge here is that while the Parameters dialog is open, other changes can be made that weren't made by the Parameters dialog itself. This is particularly true now that we allow all sorts of actions through to the main section. However, it could also include changes made by surfaces, MIDI controllers, etc. Changing a parameter could even cause a change to another parameter that OSARA doesn't even know about. We even know of cases where changing a parameter causes the list of parameters to change; see #706. That makes it very difficult to undo in any shape or form because we can't reliably assert that only our code made changes during a given period of time.

Beyond that:

1. For REAPER undo blocks, I'm pretty sure you have to begin an undo block immediately before making a set of changes, make the changes and then end the undo block. I don't think you can begin it before opening a window and then end it when the window closes. Otherwise, things would get very messy if something else triggered an undo block while the window was open.
2. I think OSARA reverting the changes it made itself would be pretty tricky to implement. Most FX parameters use the same API function, but other parameters don't. That means the revert code would somehow need to use the Param abstraction, but the dialog only currently tracks one parameter at a time. I guess we could add each param instance to a list with its initial value after a change is made to that parameter, but that gets really messy if the same parameter is changed again later, especially if we eventually manage to refresh the parameter list when a parameter change causes the parameter list to change; see When the Parameter combo box in the Parameters dialog gets focus, rebuild the parameter list. #707.

It would be fairly trivial to add undo points for every parameter change, but I'm guessing you don't want this. In fairness, this is what happens when you nudge track volumes, for example.

[ScottChesworth]

A lot of things I hadn't considered there and I don't have answers to any of the difficulties. Thanks for explaining.

It would be fairly trivial to add undo points for every parameter change, but I'm guessing you don't want this.

I mean, it's not what I had in mind, but I can imagine it being helpful when exploring parameters with complex relationships or biting points that are tricky to find. In a situation where you end up saying "oh no, I broke it", being able to hit Control+Z straight away would be good.
Could an undo block begin each time a new slider gains focus?

[ScottChesworth]

Hmm even if changes could be wrapped in undo blocks per slider though, I think the window would have to be dismissed and reopened before the undid state could be shown?

[jcsteh]

Could an undo block begin each time a new slider gains focus?

Same problem: there is still an indefinite period of time between when one parameter is focused and another is focused, during which just about anything could happen. I'm not even sure how REAPER would cope with an indefinitely open undo block like that. I guess tying this to a single parameter would make it easier for us to revert to the original value ourselves, but that couldn't be done with an undo block.

[jcsteh]

Hmm even if changes could be wrapped in undo blocks per slider though, I think the window would have to be dismissed and reopened before the undid state could be shown?

Currently, yes, but that's a separate bug that needs to be fixed, as it also applies to changes from other places like control surfaces. I thought we had an issue on file for that, but if we do, I can't find it.

Btw, I just (re)discovered that this one is a duplicate of #92. It seems I even tried to implement this and ran into other problems that I forgot about.

[ScottChesworth]

I thought we had an issue on file for that, but if we do, I can't find it.

Might be #706? Seems closely related. Shall we close this and do future work over there seeing as other things proposed here aren't implementable?

[jcsteh]

No, different bug. That one is about refreshing the list of parameters. The one mentioned above is just about refreshing the value of the current parameter. The latter is (probably?) much simpler than the former.