AudioUnit and probably VST3 are designed that processor and editor (and even more than one editor per processor) can run on different computers.
To communicate something between processing and editor (for example waveforms) you can’t use the processor-pointer in the GUI anymore.
We need something like
postMessageToProcessor (int MessageID, MemoryBlock& ) and handleMessageFromProcessor(int messageID, MemoryBlock& )
in the AudioprocessorEditor
and the equivalent in the Audioprocessor
postMessageToEditor (int MessageID, MemoryBlock& ) and handleMessageFromEditor(int messageID, MemoryBlock& ).
The getAudioProcessor() method in AudioProcessorEditor should be removed.
Interesting. It sounds more like the sort of feature that sounds like a good idea, but probably no host will ever implement it! Certainly I doubt if anyone’s ever written a plugin that would work like that, so am not in a massive hurry to look at it.
But like you say, it would be good to have some clean methods for passing info between the UI and processor, if only to help with the threading issues. How best to do that is a big question! Maybe a combo of some kind of parameters that can be set, and a binary blob interface like you suggest here.
yes, it would be nice to have something like that.
I had this idea while i was reading this topic. http://www.kvraudio.com/forum/viewtopic.php?t=198125
Someone on the thread (not i) said that juce plugins are crashing when opening two UIs of the same plugin in aulab. Maybe this is interesting for you.
I never knew AUlab let you do that - yes, it probably would cause a problem. Multiple UIs are impossible in VST and RTAS (and in every host I know of) so I never made it a priority to support them.