Assertion Failure in AudioPluginHost

Getting Started
1

I am doing the first Audio Plugin Tutorial, but when using AudioPluginHost.jucer I scan for new VST3 plugins I get the the following error message:
JUCE Assertion failure in juce_VST3PluginFormat.cpp:232
I am using JUCE version 7.0.5 with XCode

2

That assert appears to mean that the function is to be called from the message/GUI thread and not a background or real-time thread. If you’re still getting the problem, you could try posting a little more info so others can reproduce the problem or spot something that might be wrong.

1 Like
3

This is the function that calls jassert, found in the file called “juce_VST3PluginFormat.cpp”

/** Gives the total number of channels for a particular type of bus direction and media type */
static int getNumSingleDirectionChannelsFor (Vst::IComponent* component, Direction busDirection)
{
    jassert (component != nullptr);
    JUCE_ASSERT_MESSAGE_THREAD // this is line 232

    const auto direction = toVstType (busDirection);
    const Steinberg::int32 numBuses = component->getBusCount (Vst::kAudio, direction);

    int numChannels = 0;

    for (Steinberg::int32 i = numBuses; --i >= 0;)
    {
        Vst::BusInfo busInfo;
        warnOnFailure (component->getBusInfo (Vst::kAudio, direction, i, busInfo));
        numChannels += ((busInfo.flags & Vst::BusInfo::kDefaultActive) != 0 ? (int) busInfo.channelCount : 0);
    }

    return numChannels;
}

The error happens when I scan a folder for new or updated VST3 plugins.
Scanning for AU or LV2 plugins works fine.
The plugin I coded is still blank, it only shows the “Hello World” prompt and does nothing else.

4

If you have other VST3 plugins installed, the AudioPluginHost may be failing with one of those before it even gets to scan your plugin. What is the call stack leading to the asserting line in the Juce plugin hosting code?

2 Likes
5

I don’'t think that other VST3s are the problem. If I delete all the data of my plugin the scan doesn’t fail, but if I rebuild then it give the same error.
Here is the output I get:

6

I’m having this issue too; it is caused by other plugins, and the plugins at fault (so far) are several Arturia plugins I use in my DAW, on the same machine I’m using to develop. Could the scan be made more fault-tolerant?

The call stack looks like

#0	0x0000000100325a50 in juce::DLLHandle::getPluginFactory at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors_headless/format_types/juce_VST3PluginFormatImpl.h:1104
#1	0x00000001003229a8 in juce::RefCountedDllHandle::getPluginFactory at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors_headless/format_types/juce_VST3PluginFormatImpl.h:1225
#2	0x0000000100477f7c in juce::VST3PluginFormatHeadless::findAllTypesForFile at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors_headless/format_types/juce_VST3PluginFormatHeadless.cpp:80
#3	0x000000010012e868 in CustomPluginScanner::findPluginTypesFor at /Users/andrewwyld/Documents/dev/JUCE/JUCE/extras/AudioPluginHost/Source/UI/MainHostWindow.cpp:131
#4	0x00000001002ec9c0 in juce::KnownPluginList::scanAndAddFile at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors/scanning/juce_KnownPluginList.cpp:195
#5	0x00000001002ef1d0 in juce::PluginDirectoryScanner::scanNextFile at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors/scanning/juce_PluginDirectoryScanner.cpp:113
#6	0x000000010039d404 in juce::PluginListComponent::Scanner::doNextScan at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors/scanning/juce_PluginListComponent.cpp:379
#7	0x000000010039cfd8 in juce::PluginListComponent::Scanner::ScanJob::runJob at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_audio_processors/scanning/juce_PluginListComponent.cpp:392
#8	0x00000001005e2e54 in juce::ThreadPool::runNextJob at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_core/threads/juce_ThreadPool.cpp:389
#9	0x000000010062ae54 in juce::ThreadPool::ThreadPoolThread::run at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_core/threads/juce_ThreadPool.cpp:50
#10	0x00000001005df898 in juce::Thread::threadEntryPoint at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_core/threads/juce_Thread.cpp:110
#11	0x00000001005dfc5c in juce::juce_threadEntryPoint at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_core/threads/juce_Thread.cpp:132
#12	0x00000001006380ec in juce::Thread::createNativeThread(juce::Thread::Priority)::$_0::operator()(void*) const at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_core/native/juce_Threads_mac.mm:159
#13	0x000000010063804c in juce::Thread::createNativeThread(juce::Thread::Priority)::$_0::__invoke(void*) at /Users/andrewwyld/Documents/dev/JUCE/JUCE/modules/juce_core/native/juce_Threads_mac.mm:143

Specifically, it’s asserting that the factory pointer is nonnull, which for whatever reason is not the case with these plugins. Skipping the assert caused a run failure later on.

My Projucer version is 8.0.12.

The list offending plugins are these, and now it knows about all of them it seems to be ignoring them happily:

image
image700Ă—450 14.3 KB