How to debug a failing VST3 plugin?

[chetgnegy]

I’m trying to open a VST3 on Linux in the Plugin Host. I’m hitting this error: “The following files appeared to be plugin files, but failed to load correctly”

I’m trying to put debug lines in the scanning/format libraries, but gosh that’s painful. How can I easily figure out what the problem is?

So far I know I can do this to see if linker symbols are available in the VST3. These are working.
nm myplugin.vst3 | grep moduleEntry
nm myplugin.vst3 | grep VSTPluginMain

I’m seeing this, but since I’m using a combination of cmake (for the plugin host) and building the plugin using bazel, I’m not sure how this is configured.

Plug-In Host won't open any plugins

Every time I try to scan for plugins with the plugin host, I get the message “Note that the following appeared to be plugin files, but failed to load correctly:” I know this is not because of any error with the plugins, as they run fine in FL Studio, and the plugin host gives the same error even with the example projects. Does anyone know why this is and how to fix it?

[chetgnegy]

It appears both are 64 bit (5th bit is 02)

How to determine if a linux binary file is 32-bit or 64-bit?

$ od -t x1 -t c AudioPluginHost | head -n 2
0000000  7f  45  4c  46  02  01  01  03  00  00  00  00  00  00  00  00
        177   E   L   F 002 001 001 003  \0  \0  \0  \0  \0  \0  \0  \0
$ od -t x1 -t c myplugin.vst3 | head -n 2
0000000  7f  45  4c  46  02  01  01  03  00  00  00  00  00  00  00  00
        177   E   L   F 002 001 001 003  \0  \0  \0  \0  \0  \0  \0  \0

[chetgnegy]

Learning a lot. Turns out .vst3 is a whole package containing the .so file. I was just building the .so and changing the extension, which is clearly wrong (but seemed to work for VST1 in the past). I’m learning a lot here. Some of the reason I’m bumping into this is because I’m using a different build system, so feel free to roll eyes at that.

If someone can point me to the part of the JUCE codebase that makes all the auxiliary files that populate the .vst3 folder (or AU cause I know it also is a folder structure), I’d love to leverage what JUCE has instead of my own custom scripts if possible.

[reuk]

@chetgnegy

Turns out .vst3 is a whole package containing the .so file.

This is only true on Linux/Windows since VST 3.6.10. Before that, VST3s were a single shared library with a vst3 extension. For compatibility with older plugins, hosts must be able to load both formats, single-file and bundle.

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Format.html#for-the-windows-platform

@chetgnegy

If someone can point me to the part of the JUCE codebase that makes all the auxiliary files that populate the .vst3 folder

A good starting point is here:

juce-framework/JUCE/blob/a7d1e61a5511875dc8f345816fca94042ce074fb/extras/Build/CMake/JUCEUtils.cmake#L1094-L1121

Note that this is quite involved in recent versions of VST3. The bundle contains a metadata file called “moduleinfo.json” that is contained in the final bundle, but which is derived from the plugin shared library. In order to create this file, the plugin must be loaded by a helper tool during the build.

[chetgnegy]

I’m sure this is really helpful, it might even be exactly what I need, but as I’m unfamiliar with CMake, I’m sort of at a loss for how to get started. Is there a terminal command where I invoke CMake using the .so that I’ve made and it builds the .vst3 folder?

I can see how that might be problematic from a workflow standpoint as the .vst3 folder supports different platforms and the .so is already compiled, though.

For now I’ll go read the JUCE docs on CMake, but any advice you have is appreciated.

[chetgnegy]

Alternate way to pose my question: Is there a way to leverage these CMake instructions without having my entire codebase described to CMake? I can already build the binary from c++, I just need to assemble it.

[reuk]

@chetgnegy

Is there a way to leverage these CMake instructions without having my entire codebase described to CMake?

No, the JUCE CMake support doesn’t provide any way to convert existing shared objects into VST3 bundles.

That said, as I mentioned above, almost all VST3 hosts (including the JUCE AudioPluginHost) are able to load VST3 plugins in both bundle and non-bundle formats. I would be very surprised if the issue you were initially facing was caused by the plugin being a single file.

[chetgnegy]

I see.

I was trying it with the plugin host. I found it was trying to open a dll at /home/chetgnegy/.vst3/StreamPlugin.vst3/Contents/x86_64-linux/StreamPlugin.so, which defied my expectation that the single file package at /home/chetgnegy/.vst3/StreamPlugin.vst3 was sufficient. BTW, I had also tried having that same file called /home/chetgnegy/.vst3/StreamPlugin.so as I had done with VST1.

[chetgnegy]

For those that follow my stupid chronicles (lol), I got it working in the plugin host by patching together the VST3 folder structure and using vst3’s moduleinfotool to generate the internal metadatafile “moduleinfo.json” using the StreamPlugin.so binary that my own toolchain generated.

Still haven’t been able to get the standalone .so file to work. Suppose I try to sell this my plugins someday… am I a jerk if I don’t support versions of VST that are less than 3 or the standalone package? Seems like VST3 is widely supported enough that that’s fine.

[bwall]

Please be aware that you cannot sell the old VST plugins unless you already have a license agreement with Steinberg. They stopped issuing licenses a few years ago. So all you can sell is VST3.

[chetgnegy]

Understood and thanks! My intent is neither to sell them or to build them at all. If those who are actively selling have thoughts about whether their users care/don’t care about old formats, please chime in.