When traversing the history of actions, cable soloing is also undone or redone as part of the history. The cable soloing event doesn't show up by itself as an action on the history panel though. It seems instead to be included as part of the action that preceded it. Moreover, it is possible to corrupt the history by going to an action before the cable soloing took place and reversing the cable soloing. If you do this, as you advance through history and reach the event that includes the original cable soloing action, the app will display the "Cannot execute local history" dialogue.
I would expect any action that involves changing how the content of an arrangement is visualized/monitored (other candidates are the expanding and collapsing of time-line regions and changes to the time-line loop segment) to be excluded from history (it complicates checking the effect of a given action on a sound and it could also potentially create problems in a collaboration). History should include only actions that -change- the content of an arrangement.
Steps to reproduce:
-
Create a new project.
-
Drag a Tonematrix to the desktop and connect it to the Stereo Output.
-
Show the history panel and create three steps on the Tonematrix. Three "Edit step" actions are logged in history.
-
Solo the Tonematrix's cable so that it turns green. Nothing new shows on the history panel.
-
Delete the three steps you created on step 3. Three new "Edit step" actions are logged in history.
-
Go back four events in history. The cable soloing is undone as part of the creation of the third step (third "Edit step" event).
-
With the history position before the third "Edit step" event, change the soloing of the Tonematrix's cable.
-
Advance the history (redo). When you reach the third "Edit step" event, the "Cannot execute local history" dialogue appears.
Comments (4)
It actually includes a history bug.
Regarding event history, here's one example of how it can be corrupted.
I can imagine that this is difficult. I can also understand now why a cue operation would need to be kept in history, although it doesn't really contribute to modify the arrangement. The problem is how this event (cue) seems to attach itself to the previous history event. It's like in some contexts it is treated as an individual event, and in others as part of another event, if I understand this correctly.
To me cuing is just a view thing - not a modification. The same as visually zooming to a device. So I'd be fine with the described behavior.
Though, that doesn't affect the difficulty of implementation.