I started using pluginval as a part of my building process. In some of my plugins, especially AU versions of them, I’m getting this error: NaNs found in buffer – Expected value: 0, Actual Value: 170 (or another number). I tried placing a breakpoint in pluginval where the error is triggered, but it doesn’t show where the error is generating in the plugin under test.
I would start with writing a function like
void checkForInvalidSamples (const dsp::AudioBlock& blockToCheck)
auto numChans = blockToCheck.getNumChannels();
auto numSamps = blockToCheck.getNumSamples();
for (auto c = 0; c < numChans; ++c)
for (auto s = 0; s < numSamps; ++s
auto sample = blockToCheck.getSample (c, s);
jassert (!std::isnan (sample));
// Probably also this ones
jassert (sample <= 1.0f);
jassert (sample >= -1.0f);
and put it at the end of your plugins processBlock function, passing in the buffer that you just processed. Then make sure to run a debug build and see which channel/sample triggers one of the assertions. This might give you a first hint. If your processBlock call contains multiple chained processing calls, moving the function up until no assertion is hit can then narrow down the processing call that creates the invalid samples. Go into that function and put the check function in there and do the same until you find the place the error happens. Most likely inspecting all values while the debugger stopped at an assertion will reveal the root of your computation error.
So: Good luck with debugging
thanks. this helped me figure out what was going wrong.
I also noticed that an allocation error gets catched by pluginval if I use strings in the audio thread. To be clear, I don’t create strings during the processing, but in the init methods of some of my classes I have a setName(const String&) that I use. To get rid of these errors, I have to comment any myItem.setName(“blabla”) I can have in prepareToPlay.
Are you sure it checks for allocations during
prepareToPlay calls? It should be ok to allocate memory in that, it should only be checking for allocations during
that’s what I thought. In prepareToPlay I call a method that initialize every DSP class I need. In some of them I have a setName or a init(const double sampleRate, const String& s). Pluginval reports allocation errors when these are called and I’m sure they are never called during processBlock
You can run
pluginval from the IDE and set a breakpoint in the allocation detection to be sure.
This is detailed here: https://github.com/Tracktion/pluginval/blob/develop/docs/Debugging%20a%20failed%20validation.md
Thanks dave, I have already done that. I’ve been able to catch where it comes from, but I’m wondering why a String is causing this when it’s triggered during SR/BlockSize changes in pluginval. Shouldn’t be safe to allocate a String during initializations?
Can you show me the stack trace?
The only place I can see these should be caught is in the “Allocations during process” test here:
instance.processBlock (ab, mb);
I guess I have finally found what’s going on. The init with the string that’s causing that allocation issue is also triggered when the user enable/disable the oversampling. Since the OS is set by a parameter, I have this update (a call to the method that inits the DSP classes) together with the other parameters. The processBlock calls the updateParameter method on each block, so the assert is correct.