Hey there,
today I noticed, that enabling/disabling plugins will not be listed in the MixConsole history and therefore cannot be undone or redone.
Here a video where the issue is shown, first i bypass some plugins, which works fine, but then I disable/reenable some of them and nothing happens in the left zone.
Steps to reproduce:
UNDO/REDO mixer works for anything that is automatable.
There is no word about that in the manual, so my guess is that nobody really thought about that.
This is a problem, as this can become quickly a source of error when using the mixconsole history.
Also, there is no logical explanation, why this should not be listed in the history. Or do you have any?
The main purpose of a undo/redo operation is to come back to a previous state in a program. This is not possible when you’re enabling/disabling plugins.
As said, turn on/off plug-in is not automatable, and the mixer undo is an extension of automation. It records every plug-in parameter changes, the same goes to the quick link and the channel link as well:
I agree it ruins mixer undo in a way and this should be written in the manual, but that’s how the function is implemented. It is indeed disappointing but is quite logical.
Nope, that is not correct.
A good example of other operations which are not automatable, but are listed in the mixconsole history are:
The mixconsole history lists all those operations, just not enabling/disabling plugins.
Don’t know how you come to that conclusion. AFAIK automation changes are not even listed in the Mixconsole history, as they are part of the Edit history.
I mean if a parameter is automatable, it is reported to the mixer, listed and recorded in the history.
Turn On/Off is not automatable parameter and it is a plugin instance’s function, thus the change cannot be detected by the mixer. All the listed mixer operations you’ve mentioned are mixer functions, so the mixer knows the change.
Your explanation does not make any sense. Enabling/Disabling is also a mixer function, as are all the other operations. Tell me why a plugin host should not be able to detect a disabling/enabling operation, if you as a user use the mixer to do it?
If Cubase can show you the state of the plugin (active/blue or inactive/black) and is able to save/reload it with track presets and on reopening projects, it is very well capable of detecting the change.
I think the following issues should be fixed simultaneously, I don’t see the need of opening separate topic for each one :
When bypassing the Insert and Strip racks when they are empty, it doesn’t show in the History.
However, when there’s at least one plugin inserted or active strip effect, then the rack bypass does show in the History.
For example, if the user is used to invoke the undo command to revert their actions, it would undo the action that was done before bypassing the rack, therefore undoing something else than reverting the bypass, same as the main issue that was discussed in this topic (disabling plugins).
On a same channel, when no Strip effect is loaded and we bypass the Strip rack, it reverts to not bypassed as soon as we bypass the EQ rack.
If we first bypass the EQ rack then the Strip rack, then both are now bypassed at the same time, but when we enable the EQ rack again, then it also enables the Strip rack.
The Strip rack only becomes independent when there’s at least one effect loaded.
When selecting a track/channel in the MixConsole Visibility tab, selecting a different track/channel in the Project window, and focusing back to the MixConsole window by clicking its header / alt+tab / or selecting it from the task bar, the previously selected track/channel in the MixConsole Visibility tab appears selected again, but only the name is highlighted in white, while the check mark, track icon and number all become back.
The bug doesn’t occur when focusing the MixConsole window by clicking inside it, you must focus it by using OS controls as explained above.
It can also be triggered by holding Ctrl and clicking a track in the Visibility tab (when the window isn’t yet focused of course), and the track you click must be different than the one that was selected at first.
If multiple channels were previously selected in the MixConsole, only the first selected channel (when using ctrl, shift, or click drag) will glitch out.
Sometimes the channel name becomes black, but then the track icon and number get highlighted in white. I still haven’t find any specific trigger for this " other way around" variant, as it seems to happen randomly.