Anouncing "pluginval" an open-source cross-platform plugin validation tool

Audio Plugins
114

I’m not sure how this is actually possible?
Are you sure you don’t have some code in your plugin that’s saving settings to a file somewhere?

115

nevermind, I found the problem.

on a separate note, is anyone getting this assertion after cloning, building, running in xcode:

Starting test: CommandLineTests / Command line parser...
!!! Test 1 failed: An unhandled exception was thrown!
JUCE Assertion failure in juce_UnitTest.cpp:280
116

Sorry, I think was due to a change in juce::ConsoleApplication when I updated and rushed through. Will get a fix out today.

117

Should be fixed on the tip now. Just creating some new releases.

118

Can anyone verify if having DBG messages in DSP code might cause allocations on the Audio Thread? I keep getting allocation test failures on level 10 and 9 when testing my plugin on debug mode. When I compile and test in release mode, those tests start passing. The only thing I can find is that DBG messages are stripped out.

Separately:
I had 2 suggestions for PluginVal:

  1. it would be awesome to have a slider that lets us control the time when parameters are sent, so we can get a glimpse of their changes.
        // Set random parameter values
        while (--numBlocks >= 0)
        {
            for (auto parameter : parameters)
                parameter->setValue (r.nextFloat());

            ut.resetTimeout();
//            Thread::sleep (10);
            Thread::sleep(250); //can we get a slider for this time so we can see our GUI change?
        }
  1. the editor’s top is hidden by the menu bar on OS X.
        if (editor)
        {
            editor->addToDesktop (0);
            editor->setVisible (true);
//make room on OS X so we see the full editor window
            auto userArea = Desktop::getInstance().getDisplays().getMainDisplay().userArea;
            editor->setTopLeftPosition(userArea.getX() + 10,
                                       userArea.getY() + 10);

            // Pump the message loop for a couple of seconds for the window to initialise itself
            MessageManager::getInstance()->runDispatchLoopUntil (200);
        }
119

DBG ("something") will allocate. Just step through the process in the debugger and you’ll see what’s going on.

120

The binary build from github for Windows doesn’t appear to be working anymore. I get no output out of VST3 plugins on the GUI console. I first thought that maybe it was because none of the plugins I tested did anything out of the ordinary. I then tested a plugin of mine where I put an access violation on purpose in prepareToPlay. pluginval still reported nothing unusual happening.

121

When you say is “doesn’t appear to be working anymore”, what does pluginval output?

Also, what options have you go set? If you use the “–validate-in-process” option, does it crash the app?

And does VST2 work? Is it just VST3?

122

“pluginval v0.2.3 - JUCE v5.4.3” is the only output I get in the GUI console when starting the testing in an external process.

In-process just makes pluginval immediately disappear with my intentionally buggy plugin. I didn’t even get the Windows crash dialog.

If I remove the intentional bug in my plugin, pluginval seems to be working when doing the testing in-process.

123

Hmm, it sounds like it is working, but it’s crashing (as expected) before the output can be piped back to main process. That’s why you don’t get much of a log.

That shouldn’t happen though, the stack trace at the time of the crash should be sent back to the parent process.

If you try to validate other plugins does it work or do you always get a blank log?

Also, try running it from the command line with the “–validate-in-process” option. Does the log appear there or is it also truncated?

124

Great suggestion. I feel good.

125

I have an issue with a plugin with sidechain. It seems to work ok so far in several DAWs.
But when tested, I always hit this assert (EditorStressTest) in juce_AudioProcessor.cpp in setPlayConfigDetails

// if the user is using this method then they do not want any side-buses or aux outputs
success &= disableNonMainBuses();
jassert (success);

Pluginval 0.2.9, JUCE develop tip.
Any help? Can we ignore it?

126

Probably worth looking in to why disableNonMainBuses fails in your plugin?

I think that test sets a 0 sample rate and block size to see if your plugin can handle that before opening the editor.

127

I’m quite confused honestly. I don’t see why disableNonMainBuses should fail really.

So, I’ve tested the NoiseGatePluginDemo which has sidechain. The AU hits the same assert, while the VST3 hits the assert just below it:

// the processor may not support this arrangement at all
jassert (success && newNumIns == getTotalNumInputChannels() && newNumOuts == getTotalNumOutputChannels());

I don’t understand why EditorStressTest calls setPlayConfigDetails:

This is called by the processor to specify its details before being played.
Use this version of the function if you are not interested in any sidechain and/or aux buses and do not care about the layout of channels. Otherwise use setRateAndBufferSizeDetails.

I’ve tried setRateAndBufferSizeDetails and so far no asserts are hit testing both AU and VST3.

128

I think you’re right. setRateAndBufferSizeDetails is probably the more appropriate method here.
I’ve updated it now: Avoided issues disabling busses during an editor test · Tracktion/pluginval@82df2ea · GitHub

1 Like
129

Is there a way to test the plugins that have AU validation failure? I’m trying to figure out why my AudioUnits are sometimes even not recognized, or why they can’t be randomly not loaded, but I don’t see them in the plugin list :frowning:

130

I don’t think so I’m afraid. If they’re not recognised by auval, it usually means the AudioComponentRegistrar hasn’t registered them so JUCE won’t be able to find them either.

There was a GitHub issue about this here but I don’t think there was a definitive resolution.

131

It’s very unfortunate because there is no way to debug when this fails… And no indication why :frowning:

132

Is there a place where findPluginTypesFor is defined? One of my plugins is oddly visible by pluginval (validated properly by auval although others that are also created are not visible), but I still don’t know why it cannot open it when auval does :frowning:

133

Actually found that this returns in my plugin:
if (MessageManager::getInstance()->isThisTheMessageThread()
&& requiresUnblockedMessageThreadDuringCreation (desc))
return;

So as requiresUnblockedMessageThreadDuringCreation(desc) returns true, then the audio unit is not loaded…