getActiveEditor() and communication between filter and UI

I’ve read elsewhere in this forum that in a properly designed plugin the filter object shouldn’t need to know anything at all about the UI. What if however you’re building a plugin that loads data from a file through the UI that the filter will need, maybe an impulse response file or something. This might not be a great example but surely there will be times when the editor must have a way of reading info from the UI. Is getActiveFilter() the best way to proceed with this or can anyone make some better suggestions? As it stands calling getActiveFilter() in my filter constructor returns NULL so I’m stuck either way!

You seem a bit confused about whether the filter shouldn’t have a pointer to the UI or vice-versa…

Basically, in a good design, the UI obviously needs a pointer to the filter that it controls - and that pointer should be given to the UI when it gets created (by the filter).

But there could be multiple UIs all controlling the same filter, so you shouldn’t have a pointer in the other direction. There’s really no good reason I can think of to ever do so anyway. If a UI wants to know when a filter’s property changes, you should implement a listener pattern so that UIs (or any other object) can register with the filter and be told when something changes.

Thanks Jules, that makes perfect sense, you’re right, I was confused. Just last thing, in my standalone version my standalonefilterwindow class opens a config type file that contains the numbers of parameters needed. I want to pass this file to a string member in my filter class and parse the info in the filter constructor and then go about setting up the different parameters. Does this sound like a reasonable way to go about the task?

Yes, of course - the UI is there to control the filter, so you should make it call whatever filter functions it needs to.

Super.

Sorry to revit this but I’ve another question. I would like my standalone window to be able to pass information to my filter. No problem there except the information must be known when the filters constructor is being called. I quickly edited filter constructor so that I could pass a string when calling createPluginFilter() which I also changed so that it accepts a string. This worked great for my standalones but when I tried to build again as a plugin I get an unresolved external. So I changed the juce_VST_wrapper.cpp so that it knows createPluginFilter() now takes a String parameter. I really don’t like messing with juce files, is there any other way I can do this?

Why not just set the information after the filter has been created?

For reasons that have suddenly become unclear to me! I start an external process in my filter constructor. This has to be started in the constructor for plugins but not for standalones. I guess I can just add a method to start the process which I can call from my standalone window. No call will be made to this function when running as a plugin, that might do the trick.