I’m fairly surprised nobody else has come across this, but it took me days of debugging off and on over several weeks to figure out. I’m now looking for a solution.
AudioProcessorValueTreeState to manage my plugin state, along with an
UndoManager which is set in the tree state’s constructor as required. Both are of course owned by the derived
At the end of my
AudioProcessor constructor, I add all my parameters to the state via
createParameter. So far so good.
I have undo/redo buttons in my
AudioProcessorEditor hooked up to the
changeListener callback of the
UndoManager, such that when the state changes, I can update the status of the buttons (i.e. greyed out if no undo or redo can be done). This is where I start to have problems.
After plugin creation, setting the state tree of the
AudioProcessorValueTreeState seems to generate at least one (incomplete?) action on the
UndoManager's stack, which causes my buttons to always begin with the undo button perusable (since there is an event leftover from adding the state tree) which seems to contain an action for adding an
id parameter object to the tree. Attempting to perform an undo causes an assert due to failing a reentrancy check in
My days of debugging have pointed me toward the fact that
AudioProcessorValueTreeState updates via a timer, and that if I wait an arbitrary amount of time before calling
clearUndoHistory(), I can get rid of the stray undo action.
My question is, is this intended behavior? Am I setting up my undo all wrong (i.e. working with the
UndoManager directly from my UI code)? How do I work around it? Clearly, there’s a way it’s supposed to work, considering it’s been implemented in big plugins like Equator…