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.
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.
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.
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.
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.
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.
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.
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.
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.