AudioProcessorGraph owning AudioProcessors?

Hi Jules & community,

I was wondering why,does the AudioProcessorGraph own the AudioProcessors ?
addNode doc says :
“This creates a new node in the graph, for the specified processor. Once you have added a processor to the graph, the graph owns it and will delete it later when it is no longer needed.”

This is a problem, if for example, you want to add your AudioProcessor to several graphs for instance. Or if your AudioProcessor isn’t dynamicaly allocated (double delete at the end of the program).
Woud it be possible to have a boolean, non-mandatory parameter to addNode to choose if we want to keep the AudioProcessor’s ownership ?

The thing about AudioProcessors is that they’re supposed to be fairly lightweight - you should be able to create and delete multiple instances of them without that being a problem, so it’s pretty reasonable that when you’re adding one to a graph, you’d just create a new instance and hand it over.

There’s no way a single instance can run in multiple graphs at the same time!! And you definitely shouldn’t be allocating them as stack or static objects - they’re transient objects that are created and destroyed when needed.

OK then I probably quite didn’t get how to correctly use them then :slight_smile:

AudioProcessors are suposed to be transient, and lightweight, so if I correctly understand, they shouldn’t require any complex initialization/destruction, right ?
Because in this case, what about VSTPlugins ? They can be pretty costly to instantiate…and still, they are AudioProcessors in juce.

Anyway, if I want to subclass AudioProcessor, I must make sure that my class enforces the following requirements :

  • constructor/destructor are light and fast
  • is always allocated dynamicaly

Right ?

Obviously they can only be as lightweight as it’s possible to make them - if you need to do lots of initialisation then that’s just the way it is. All I mean is that you can’t assume there’ll only be one instance, you need to assume that many instances can be created and destroyed at any time.

Hi Jules,

First of all I want to say thanks for your work on JUCE, it’s an amazing contribution to the community and I have enjoyed learning to use it over the past few weeks.

As for the question of AudioGraph nodes owning their processors, I do believe that this has become somewhat of a convention in the industry, though I cannot really understand why.
given that:

  1. audio processors are owners of their editors and editors nowadays are expected to be singing all dancing dreamscapes of dsp visualizations
  2. designing a complex instrument can involve complex graphs with changing topologies and compartmentalization into (many) small reusable units is encouraged
  3. most contemporary programmers can actually deal with changing samplerates and block sizes and don’t need to have everything torn down and built back up again.

To that end I could imagine that an AudioGraph Node could be implemented that upon deallocation decriments a reference instead of calling dealloc.

Is this a topic which has been investigated further at this point? (is anyone already working on a fork like this?)

Thanks in advance for your feedback,