I have encountered a problem I cannot resolve. I try to load in my app a plugin I just created with projucer. I did not change anything in the generated plugin code.
I compile the plugin code thanks to this CMakeList:
project(Reverb_v2 VERSION 0.0.1)
set (BaseTargetName Reverb_v2)
# VERSION ... # Set this if the plugin version is different to the project version
# ICON_BIG ... # ICON_* arguments specify a path to an image file to use as an icon for the Standalone
# ICON_SMALL ...
FORMATS AU VST3 Standalone
When JUCE calls the getPluginFactory function it hit the: jassert (factory != nullptr) where it says.
// The plugin NEEDS to provide a factory to be able to be called a VST3!
// Most likely you are trying to load a 32-bit VST3 from a 64-bit host
// or vice versa.
I do not understand why, is there a parameter in projucer I had missed to correctly set the plugin ?
I saw on the forum that the question has been asked many times, but never clearly answered.
How are you configuring CMake? If you’re on Windows, perhaps the comment is correct and you accidentally built the plugin for 32-bit instead of 64-bit. You can pass -A Win32 or -A x64 when initially configuring the project to control the platform name of the Visual Studio generator.
Also, how are you testing the plugin? It sounds like you might be using the AudioPluginHost. If this is the case, how did you build the host?
Are you passing the path to the Reverb_v2.vst3, or to the Reverb_v2d.so?
I think there are a few things that might cause problems in your code:
The pluginDescriptions array will live for the lifetime of your program, so it will grow and grow every time a new plugin instance is scanned.
If the knownPluginList doesn’t find anything, pluginDescriptions may be empty when its first element is accessed. This is undefined behaviour and is likely to crash the program. Alternatively, because the array is static, you might end up instantiating a ‘previous’ plugin instead.
The errorMessage argument is an out-parameter that modifies the string to contain a description of the error if plugin creation fails. You should pass an empty string to createPluginInstance, and inspect it after the function to check that it is still empty (i.e. no error occurred).
I’d recommend the following:
Use KnownPluginList::scanAndAddDragAndDroppedFiles to identify plugins, rather than scanAndAddFile. This function has a simpler interface, and will recurse into plugin bundles automatically.
Remove all static variables with function scope. These are not necessary, and are likely to cause issues in the future, e.g. if you need to call the function from multiple threads simultaneously. Your knownPluginList should probably be a data member of the class, pluginDescriptions should be function-local but non-static, and vst3PluginFormat is not required at all.
Does the plugin open in other hosts? If not, that might indicate a problem with the plugin itself. If it does open in other hosts, then the problem is likely to be on the hosting side.
You could also try loading some other known-good plugins in your host. If you’re not able to load anything in your host, then that will give you some hints where to look. However, if you’re only unable to load the Reverb_v2 plugin, then the problem is probably in the plugin.
You can test whether the plugin bundle exports the correct function by running nm path/to/dso/Reverb_v2d.so > symbols.txt and then search in symbols.txt for GetPluginFactory. There should be a T next to the name of this function in the output.
If it does, you could try sticking a breakpoint at VST3PluginFormat.cpp:995 and step through DLLHandle::open(), checking whether the library opens successfully. If the library loads but doesn’t contain GetPluginFactory then something’s prevented this symbol from being emitted in the plugin build, and I’m not sure how that could happen… If the library doesn’t load at all, then something about the build has made it incompatible with this host. Perhaps it depends on different (standard) libraries.
Does the plugin load in any non-JUCE hosts, such as REAPER?
Maybe CMAKE_DEBUG_POSTFIX is being set somewhere? Are you using any other libraries in your CMake project that might set this variable? You could try reconfiguring and force this variable to be an empty string, and see whether that removes the d suffixes.