Small AudioProcessor::addListener request

General JUCE discussion
1

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
2

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.

3

: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…

4

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.

5 
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

6

Perhaps the listenerlist could be made accessible?

7

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
}
8

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

9

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?

10

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

11

…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.

12

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.

13

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