So, I have a simple wrapper application working to test my plugins, based on the StandaloneFilterWindow class.
However, this only works with live audio input since the AudioProcessorPlayer class is an AudioIODeviceCallback and connects directly to the AudioDeviceManager bidirectionally like this:
AudioProcessorPlayer <--> AudioDeviceManager
If I want to use an audio file as input instead, it seems like I need a way to chain together something like this:
I don't want to create a filter graph and use an AUFilePlayer since I want the wrapper to only use minimal screen area around the plugin GUI, just a banner with Play/Pause and an Open button.
Is there an "insert" technique I'm missing?
You might want to check out AudioProcessorGraph. It can be given to the AudioProcessorPlayer. Then create a wrapper processor for the AudioTransportSource and add the wrapper and your plugin to the graph. Connect the wrapper to your plugin and connect your plugin to the graph's outputs. when you want to use live input then connect your plugin to the graph's inputs.
Ah, when I said "filter graph", I actually meant AudioProcessorGraph:)
So, your suggestion is effectively to write my own version of AUFilePlayer (which was OSX only being an AU) by putting the TransportPlayer and SourcePlayers inside an AudioProcessor wrapper.
I suppose the other way is to combine AudioProcessorPlayer and AudioSourcePlayer classes into an AudioProcessorSourcePlayer hybrid.
Still hoping there's a simple trick to perform an instert or redirection...
You don't need to use AudioSourcePlayer. Just make your own AudioProcessor that has a transport source member and in the processBlock map the AudioSampleBuffer to an AudioSourceChannelInfo.
It isn't super simple but I'm not aware of how it could be done more simply. The graph provides the means to connect processors and the processor player will play the graph. You could manually operate your plugin and the transport source in an audio callback I guess.