Possible to find the number of connections in an AudioProcessorGraph

Hello

I am writing a plugin that records incoming audio in a graph. When a command is sent to this plugin, the recording stops and the audio is written.

However, I would like to know the number of actual channels that were fed to the plugin, not the number of maximum connections, in order not to write 16 inputs if only 2 were recorded.

Is it possible, from within an AudioProcessor, to know the number of actually connected inputs ?

Thanks for your help

Hmmm probably not. The AudioProcessorGraph simply feeds in zeroed audio data. Is there a possibility to change your code in such a way that the AudioProcessor’s include a reference to the graph?

Hello

Thanks for the suggestion, but the relationship between these classes is part of the framework (in the graph class). I would like to find a way to retrieve this information without having to patch Juce but I guess that as a last resort… I could also post-process the recording by eliminating empty channels, but this is not very elegant, to say the least.

Thanks again for your reply.

Best,

Hi golinvauxb,

Hmmm…ok this will not be easy. We have had a few requests for an isConnected method in the AudioProcessor as Logic and ProTools can also disconnect inputs/outputs during playback. It’s actually difficult to correctly implement for all backends but will definitely put this in the backlog.

Fabian

Thank you. Glad to hear that my request makes sense. Keep up the good work. Juce is FANTASTIC: small, stable and most of the time, when I think of a method I would need, it’s already there.

There is however something that I don’t quite like about Juce, that is, the way raw pointers are used in several places, as arguments or return values. The documentation always explain correctly that caller/callee must/should not/will delete the object, but I think that using unique_ptr/shared_ptr (or the Juce equivalent) would help eliminate a lot of potential bugs when dealing with such pointers. Hard to fix that without breaking source-level compatibility, though.