Possible to find the number of connections in an AudioProcessorGraph


#1

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


#2

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?


#3

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,


#4

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


#5

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.