Small AudioProcessor::addListener request

Hi Jules,

Can you make AudioProcessor::addListener / removeListener virtual?
I have a wrapper for an Internal Plugin-Format, and would like to pass the listener adds/removes calls to the wrapped plugin.
All other solutions would introduce a lot of hassle.

  • chkn

Smells like a hack to me. Add/remove listener functions are never virtual, and I’d need to hear a much better argument if you want to convince me that they should be.

:cry: …so what could i do?
recreate the whole listener Management for AudioProcessor, add a listener to the wrapped class, and simulate it? (And than when you change it, its automatic incompatible), also there is a a internal logic with changeGesture etc., this smells more like a hack…

or just clean

please

PS: i think the real problem is that there is no overriding keyword in c++, but that’s another story…

Adding/removing a listener should simply update the listenerlist, and not do anything else… I don’t understand what you’re trying to achieve, but I’m sceptical about whether overriding those methods would ever be a good idea.

mmhh long story....
i have an internal plugin format (like vst/AU/etc...), which has a special functionality in it.

The plugins live not in dlls, they live as classes in my sourcecode. Just AudioProcessors.

But i use classes like PluginList && AudioProcessorGraph etc.... which working WONDERFUL (perfect!!) together with my internal format plugin-format.

There a some different implicates, how the the juce-api think, what an plugin format has to handle (editorbeingdeleted() etc.. ...), thats why i  had to implement the wrapper, without it would not be possible.

But because they are still AudioProcessors, and used them as audioprocessors, i would like to be able, to pass the listener request directly to the internal-processors. please

mmhh long story…
i have an internal plugin format (like vst/AU/etc…), which has a special functionality in it.

The plugins live not in dlls, they live as classes in my sourcecode. Just AudioProcessors.

But i use classes like PluginList && AudioProcessorGraph etc… which working WONDERFUL (perfect!!) together with my internal format plugin-format.

There a some different implicates, how the the juce-api think, what an plugin format has to handle (editorbeingdeleted() etc… …), thats why i had to implement the wrapper, without it would not be possible.

But because they are still AudioProcessors, and used them as audioprocessors, i would like to be able, to pass the listener request directly to the internal-processors. please

Perhaps the listenerlist could be made accessible?

no, because the wrapper should behave like a normal AudioProcessor, but i think i found a compromise. What about adding two virtual callback functions which inform about listener registration/deregistration
Than it would be impossible to accidentally override the addListener/removeListener methods.

add to AudioProcessor

	/**  a virtual callback method, which will be called when a listener was added */
	virtual void listenerRegistrationCallback (AudioProcessorListener* ) {};

	/**  a virtual callback method, which will be called when a listener was removed */
	virtual void listenerDeregistrationCallback (AudioProcessorListener* ) {};
void AudioProcessor::addListener (AudioProcessorListener* const newListener)
{
    const ScopedLock sl (listenerLock);
    listeners.addIfNotAlreadyThere (newListener);
	listenerRegistrationCallback(newListener);  //new
}

void AudioProcessor::removeListener (AudioProcessorListener* const listenerToRemove)
{
    const ScopedLock sl (listenerLock);
    listeners.removeFirstMatchingValue (listenerToRemove);
	listenerDeregistrationCallback(listenerToRemove);  //new
}

jules, what do you think about this solution (above)?

It all seems wrong to me… The class just isn’t designed to work like this. What about other things like setPlayHead, setPlayConfigDetails, etc which are also non-virtual? Surely you’d also need to implement all of those to create a wrapper?

setPlayConfigDetails i can set in my wrapper, setPlayHead i don’t need yet, i can see nothing wrong in it, i would say my solution is transparent

…or see it from another perspective.
I need the functionality to get informed when something attaches a AudioProcessorListener to an AudioProcessor, and this a solution that doesn’t hurt anyone.

I’ve needed to know before when Listeners were added to Processors, so +1.

Adding two tiny, empty virtual methods isn’t a big change and solves the issue. And regarding setPlayHead, etc - why shouldn’t they be virtual? They’re not called on each sample or buffer full of samples, so the tiny extra overhead of a virtual method isn’t significant, and as you argue, there are good reasons for overriding them.

I tend to think that inheritance is very much overused in C++ - but if you’re going to do it, you should do it right and make sure that anything that people might want to get notified on is virtual.

Ok, I hear you. I think I will just make the add/remove methods virtual, it’s the simplest solution.