How do I reach audioTestBench -> audioFileR​eader.Samp​lesPerFram​e for use in my plugin?

I'm creating a Real-Time frame-based plugin with the System Audio Toolbox, to run through the audioTestBench. In the audioTestBench the input is set to "Audio File Reader" or "Audio Device Reader" depending on my current setup. This allows me to specify the desired number of samples per frame, a number that is relevant for the frame-based plugin code, however I'm unable to read the samples per frame into the plugin code?

Using the function "getSamplesPerFrame(audioPluginSource)" always returns the default value 256, since I'm not using "setSamplesPerFrame" to define the frame size.

So my question is, how do I reach the instance of e.g. "dsp.AudioFileReader" that is used within the UI of the audioTestBench, such that is can read the specified samples per frame within the plugin?

Answer 1

[Julia Antoniou]

Hi Kim,

There is no programmatic interface to the Audio Test Bench UI. However, you could obtain the SamplesPerFrame property of dsp.AudioFileReader by calculating the size of the input data to the 'process()' method. For example, the source code of the Audio Test Bench could be edited to include:

classdef myEchoPlugin < audioPlugin
     methods
        function out = process(plugin,in)
        spf = size(in,1);
        out = in;
        end
     end
end

[Kim Johansen]

Thanks for the answer. The lack of interface and the suggested solution, however, doesn't solve my problem entirely. Since I'd like to instantiate some vector properties in the plugin, with the same size as the input, before the process is entered.

I am aware of the possibility to declare the variables as properties and then set them equal to some zero vector at first entrance in the process, using an if-condition of first entrance. Which ended up being my workaround, however not ideal.

Thanks again for the answer.

[Charlie DeVane]

Hi Kim,

There is no interface for this because, in general, audio plugins do not guarantee a fixed frame size. The process function might receive a different number of rows every call. Your solution probably works fine in this specific context, but may encounter problems in other contexts. For example, if your plugin assumes a fixed frame size based on the first input frame, when a DAW gives your generated plugin a smaller frame, the plugin will read invalid input data and write outside the output buffer, potentially crashing the DAW. validateAudioPlugin attempts to detect such behavior, but it cannot be bulletproof.

hope this helps,

Charlie