AudioProcessorGraph ValueTree


Do I remember a mention of making AudioProcessorGraph work with a ValueTree? After watching @drowaudio’s ValueTree presentation I would really like to let JUCE handle all the undo/redo functionality in my pMix app (which is a hack of the demo host). If there are plans to change it, I can let the pMix code rot a little longer…



I’m not sure the two should be intrinsically linked like this.
AudioProcessorGraph has a very specific purpose, to connect AudioProcessor instances together in a “graph”.

A ValueTree is more of a data structure. You could define ValueTree types and properties to relate to a specific configuration of an AudioProcessorGraph but it’s unlikely there will be a one-fits-all solution for this. It will depend hugely on the abilities of your app and what types of AudioProcessors you support etc.

I fear that any forcing of AudioProcessorGraph in to a ValueTree context would be essentially the same as the ComponentBuilder class. I think this is now largely viewed as a bit of a failed experiment: Is anyone using the ComponentBuilder class?

This isn’t to say that you shouldn’t use ValueTrees and AudioProcessorGraphs in combination however, they would be very complimentary. I just think you’re probably better of rolling your own AudioProcessorGraph builder based on your specific ValueTree structure, it’s probably not something generic enough to go in to the JUCE library (but it might make an interesting tutorial or demo!)

However, I’m not a big expert in AudioProcessorGraph so it could be that it boils down nicely to a 1:1 ValueTree representation, these are just my initial thoughts…

1 Like

Unfortunately it’s not really feasible with AudioProcessorGraph as-is using a direct method of interaction similar to the audio plugin host example. This is due to the fact that AudioProcessorGraph only provides a super vague ChangeBroadcaster implementation that doesn’t tell you anything about what was changed so you can reflect it in your ValueTree model.

What you’d need to do is create a wrapper class which contains an internal AudioProcessorGraph and uses wrapper functions/objects to update a ValueTree model owned by the wrapper which can manipulate the internal AudioProcessorGraph to match its state.

I was thinking more that you’d use your ValueTree to determine the model (types of processors, how they’re connected, layout etc.) and then build an AudioProcessorGraph from that.

It might be a bit hacky to ‘sync’ the graph to the ValueTree but that’s probably the best approach for now.