i’ve discovered this while implementing the JackAudioFilterStreamer, which is somehow based around the AudioFilterStreamer. Since this class works to be a kind of host around you FilterBase plugin, there is the lack of a function that lets you create the editor of your filter (through the virtual createEditor) by calling the private createEditorInternal, in which it saves a pointer to the activeEditor. Without that function, any calls in your filter to getActiveEditor() just returns 0. And since the member activeEditor is private (in AudioFilterBase), you can’t just set it in createEditor to bypass the problem…
Ok, fair point, I’ll sort something out to get around that.
I wouldn’t recommend that your filter calls getActiveEditor() though - in a properly-designed plugin, the filter object shouldn’t need to know anything at all about the UI…
yes you are right, i’m actually testing if some classes (built as components but working also with audio flow directly) are working before i split them up in two classes, one that collects data, and the other that display the collected information in the ui. i’ve discovered this while hacking a bit the plugin, sure i’ll not use getActiveEditor() when i’ll design better the classes, but for doing fast and tricky testing, i think it should be possible too…
thx
and in reverse
the editor class gets data from the Filterbase (that’s what i use, cause the editor get’s deleted everytime a window gets closed), but as i noticed a comment in the source says that the variables in the FIlterBase class are public so that the editor can access them, however it’s not a good idea (or something like that), why is that ? what would be a proper way for the Editor to access data from the FilterBase class?
maybe have getter functions to have the objects you need to access, but before accessing them just make sure that your filter pointer exists (but should be obviously return true). The opposite (checking from filter if the gui exists) could return false…
is it possible for the editor to exist without the FilterBase class ?
i don’t think so or am i wrong?
normally, it is the filter that will construct the editor, not the opposite (if you are instantiating the plugin from a typical audio host). but if you manually instantiate your classes to build a standalone executable… well, you could do the opposite if you want, even if it is not a correct way to do it.
i typically instantiate my filter, my streamer, then i register the filter with the streamer, ask the streamer to create the gui for its owned filter… this way i can communicate between objects by filter->getActiveEditor() and editor->getActiveFilter(), obviously checking if the pointer exists.
when i’ve finished i just clear the internal activeEditor of the filter, and leave the editor Component to be killed by the Window it is attached to…
but i’m in a standalone app, the Vst/AU Wrapper just do this for you 