Currently the undo/redo commands work on parameter changes for native Bitwig plug-ins, but they should work on third-party plug-ins as well.
What problem(s) would this feature resolve?
Not being able to undo parameter changes in third-party plug-ins. Furthermore, accidentally hitting undo while working on a third-party plug-in undoes the creation of that plug-in, if that was the last “undoable” thing the user did.
When undoing parameter adjustments is restricted to native devices it makes for a less smooth overall experience because the user is unable to trust their muscle memory while working. They need to stop and consider “Will this undo command do what I expect, or will it actually undo the creation of this third-party plug-in”. This is detrimental to the flow of the creative process and slows everything down.
How does this feature fit in Bitwig as a product?
Bitwig takes pride of flexibility (i.e. using any resources at hand, including third party plugins) and how quickly you can get interesting results. A little problem like this gets in the way of the creative process.
Is there already an alternative way to achieve this on Bitwig?
Could it be implemented using Bitwig components or APIs, without Bitwig team’s support?
Could it be provided by an STV or something else reasonably integrated with Bitwig?
I really don’t understand why this isn’t higher on the list. I guess there might be more people here not using plugins that much.
In any case I think this is a rather fundamental function, trying to experiment when using a plugin is frustrating without a proper undo function. Some plugins have built in undo functions but a lot don’t, I guess those developers too thought built-in support to undo actions in their plugins was a given.
Does anyone know what is the technical root of the problem? Is this about Bitwig not implementing a feature available for VSTs plugins, or about the developers of these VSTs implementing something specific for certain DAWs to enable this undo?
Basically, is this something that the Bitwig team alone can fix, or do they need cooperation for the plugin authors?
(Also, if someone can provide a screenshot or similar of a plugin supporting undo in another DAW, we could feature it in the description.)
Hey there! I also ask myself why this important workflow feature still isn’t implemented yet.
Parameter states of external plug-ins are also being saved to presets. If a VST is nested into a device-chain and some parameter is connected to a remote control knob, that knob position is also being saved. If a specific state can be saved than it must be possible to protocol that state.
External plugin parameters (e.g. frequency, gain) are being displayed in the list of parameters of bitwig‘s device-window with the right value (e.g. kHz, dB), but if it’s connected to a remote control knob it displays a value between 0…1.
I don’t know if it’s there’s a connection, but it’s notable that it doesn‘t happen on Bitwig devices.
I asked on the Bitwig Discord a month ago, and there was a bit of discussion that might be useful to store here. This is the link to the full conversation.
Bottom line, there are technical difficulties that go beyond what the Bitwig team can do.
I explained the technical why a couple times before, but there’s no clean way to do it. Best way would be to save the entire plugin’s state whenever it changes something, but if your plugin for instance stores samples, then that’s going to eat up RAM fast. So then you either end up with the undo working with some plugins but not with others depending on how large the plugin state is, or you end up running out of RAM.
DAWs that do try to do plugin undo either only store the parameters (which means that things like selecting or changing something within a wavetable wouldn’t be undoable) or they store the entire plugin state
As far as I am aware, Undo/Redo mechanisms tend to be done using a coding design pattern known as the Command pattern. A task is broken down into individual steps with a clearly defined reversal or undo procedure. Each call by the user to undo a step involves stepping back though the chain of command steps and carrying out the undo action. The problem here is that the VST will have its own Command pattern implementation code while Bitwig has a separate Command pattern implementation for its actions. I would imagine that there are considerable problems in trying to control one undo mechanism from another - a lot more difficult that passing Cmd/Ctrl Z messages to and fro
“DAWs that do try to do plugin undo either only store the parameters (which means that things like selecting or changing something within a wavetable wouldn’t be undoable) or they store the entire plugin state”
I don’t care about it storing the entire plugin state. Changing a wavetable and needing to reverse changes to what you’ve done there…not necessary. A lot of the time you have undo in the plugin for that stuff. I just want it to remember basic parameter changes. Like knob tweaks. I don’t want it to remove the plugin I inserted when I press the keyboard shortcut for undo despite having tweaked a lot of knobs. I want it to undo the last basic knob action I made unless there were no recent basic parameter changes.
Any knobs that transmit CC values and are available for automation are able to be recognized by the DAW. I don’t need the actions that aren’t transmitted to the DAW to save to the undo stack. That’s how it is with other DAWs. There are some changes you make on a synth that can’t be reversed when you select undo and that’s fine. You learn what can’t be undone. But when you’re tweaking a filter cutoff value or an envelope value or most basic parameters that transmit CC, it should be reversible. I shouldn’t have to take note of the actual value before I make the tweak so that I can manually pull it back to that specific value it was at before.
IMO it’s not a terribly difficult thing to solve at all. Anything that transmits values to the daw and can be automated in the DAW, you can throw on the stack for that specific plugin. When you click undo, it checks the DAWs own undo stack and says hey CC101 was changed from 100 to 127 on plugin A. Now that undo was pressed, send a value of 100 to CC101 on plugin A…undo successful.
I mean I don’t know how they coded Bitwig, but you should at least be able to do basic undo in plugins for any parameters that can be automated through CC values.
On the other hand you could have an option that changes the undo system to save the entire plugin state for people with enough ram to store all that data.
Or possibly you could have it store the entire plugin state to a file instead of to the ram. It might not be as fast as you’d like, but that could also be an option that people might be willing to select. It might take a second or two for it to load the previous parameter from a hard disk drive, but because they personally selected to have it work that way (and were notified of the slowdown that would result), they wouldn’t be too bothered.
Regardless, I feel like any improvement that can happen to the undo system would be very welcome.
I think this would be too confusing. How would you distinguish between undo in the plugin and undo in bitwig when the plugin window is closed?
You just need know what you’re doing so you don’t have to undo
Undo in VST plugins has always been problematic in all DAWs. The VST spec never had a standard way of passing undo requests to the host. Either implement in clap and thats it, or make it standard for Plugins to themselvesimplements their own undo/redo.
Ableton can do it. I don’t care if it’s difficult, just note the fact that ableton can do it and it’s enough of a reason to at least investigate and understand how to resolve. Even if it’s undo support for some % of VSTs it would be better than nothing (or watching your vst unload itself, initializing whatever you were doing)
I have sent a question to Bitwig support asking if they can clarify whether fixing undo in third party plugins is something they can do or a problem that third party plugin developers must address. If they respond saying that this is something 3rd party developers must address, I will close this feature request as invalid.
The point being discussed is whether “DAW X can do it” simply means that third party developers make sure their plugin support Undo in DAW X, and they could do the same for Bitwig. According to this position, there is nothing technically that prevents developers from implementing Undo in Bitwig, not anything special that DAW X has.
Given that this is a technical question and nobody is better positioned to answer it than the Bitwig team, the best solution to resolve this discussion is to ask them and hope we will get an answer.
@here The Bitwig team has answered and we have enough information to resolve this feature request:
Bitwig cannot offer a reliable Undo feature to plugin developers because the VST standard doesn’t support this feature.
In practice, plugin developers need to implement the Undo functionality for their own plugins.
Some DAWs have developed custom solutions to bypass the lack of Undo in the VST standard, but plugin developers still need to ensure their plugins work with this custom Undo feature in each DAW they want to support. Plus, this approach has some pitfalls that may make Undo not work as expected in some cases and it may also bring performance issues.
The Bitwig team prefers to invest their time contributing to a reliable Undo implementation for the open source CLAP plugin format, an effort that has started already.
For this reason, let’s resolve this feature request so people can put their attention and votes in better places.
If there is enough interest, we could create a poll about plugins where you miss Undo in Bitwig. With enough participation, this could give us an idea about which plugins Undo functionality is more sorely missed, and maybe this would encourage these developers to ensure that Undo works for their plugins in Bitwig.
For the record, this was the fifth most voted feature request, with 108 votes.