I’m having some difficulty wrapping my head around one of the unique aspects of audio plugin design; the fact that the GUI (editor) can be destructed and constructed during the lifetime of the processor. Specifically, I’m wondering what solutions/designs people use to maintain the state of the GUI across multiple instantiations of the editor.
I understand how to update the editor from the processor, via one of the following:
Timer: implement a timer in the editor, and in its
timerCallback()determine if any GUI changes must be made;
ChangeBroadcaster: send a change message from the processor (
ChangeBroadcaster) to the editor (
ChangeListener), upon which the editor will update itself;
MessageListener: post a
Messagefrom the processor to the editor (
MessageListener), informing the editor what needs to be updated.
I prefer the
MessageListener solution, as I’m able to send custom messages to the editor. This allows me to be specific about what has changed, as opposed to the more general
ChangeBroadcaster solution. I couple this with a view model; the view model maintains the overall state information that the GUI cares about, and the messages inform the GUI what kind of update (from the view model) needs to occur.
So far so good, everything seems to work nicely. However, the problem occurs when the editor is destroyed (which could happen if the user closes the window). When the editor is constructed again, I have obviously lost the complex state of the GUI, which has evolved over time.
Two solutions come to mind, though I’m not sure how ideal or possible they are:
- I could continue using my view model approach, but force all GUI updates to be complete refreshes. This way, when an editor is destructed and constructed again, it will be able to recreate its state from the view model. However, this forfeits the granular-update approach offered by the
MessageListenersolution (as each update would become a full “refresh” of the UI).
- When the editor is constructed for the first time, I could maintain a reference to that and return it each time
createEditor()is called. However I see that this is not advised, due to the possibility of dangling pointers.
What is the preferred solution? I should add that I’m not dealing with parameters; most of the UI changes I’m working with are results of user interaction, component position/size changes, histrograms, etc.
Thanks in advance for any guidance!