Problem with Dependency Injection and createPluginFilter()

Audio Plugins
1

Hey there,

For my Plugin, I’m using a class which holds ui-parameters, in order to be used in other processing classes.
After researching a bit I learned about dependency injection and I think I got the basic grip on it.
I have my class “Parameter”

#include IParameter.h

class Parameter : public IParameter
{
 public:
        Parameter();
        ~Parameter() override;
 private:
        std::unique_ptr<IParameter> makeParameter();
};

which inherits from it’s interface “IParameter”

class IDirectivityParameter
{
    public:
        virtual ~IDirectivityParameter() {};

        virtual double doSomething() const = 0;
};

when injecting the dependency as a private member object of the PluginProcessor like this:

PluginProcessor.h:

#include IParameter.h
....
private:
    std::shared_ptr<dearvrDir::IParameter> parameter_;
}

PluginProcessor.cpp:

#include "IParameter.h"

MyPluginAudioProcessor::MyPluginAudioProcessor(std::shared_ptr<IParameter> parameter)
{
    this->parameter_ = parameter;
}

I run into problems with the generated “createPluginFilter” call at the end of the PluginProcessor.cpp because I can’t access the injected member object which needs to be returned in the constructor of the Audio Processor.

AudioProcessor* JUCE_CALLTYPE createPluginFilter()
{
    return new MyPluginAudioProcessor();
}

I know the problem occurs because this specific call is not an implementation of the Class and therefore can’t access the member variable.
Does anyone have a solution for this or can suggest another pattern to access objects across classes in JUCE while still maintaining testability?

Any help would be very much appreciated,

cheers,
Simon

2

I think you are on the wrong track. This createPluginFilter() method is the main entry point for the plugin. To use a plugin, the host will load the dynamic library and find that method to create an instance of the plugin.
You shouldn’t have to change anything here.

1 Like
3

Hey daniel,

Thanks for your quick reply.
It does make sense to leave the method untouched.
But if I can’t inject with the constructor of AudioProcessor, how else would I use the same object of my class across different classes including the Audio Processor within JUCE then?

cheers,
Simon

4

maybe just make everything structs and stop using private? Also, just because you learn a new programming technique doesn’t mean you have to use it.

you should rethink about what you’re trying to accomplish and see if you can get it done with composition first, inheritance second. it’ll keep your code simpler, and you’ll get stuff done faster.

2 Likes
5

Hey matkatmusic,

thanks for being clear about this.
I solved it with private member setters for now and it does the job and enables me to get stuff done for now :slight_smile:

cheers,
Simon