I’m relatively new to JUCE. I took a class at my university two semesters ago where we used JUCE to build plugins, and it was honestly my favorite class I took while I was there. For my final project, I built a multiband bitcrusher. A few months later, I decided to start working on it again.
I released it to the public, but two people have reached out to me saying that the VST3 isn’t showing up in their DAW, and I’m beginning to believe it’s something wrong with the plugin rather than their machine. My professor was able to get the plugin to work on his machine when he initially graded it, but that was several months ago and he hasn’t responded to me.
The plugin works perfectly fine on my machine, and I did my best to try to get rid of global paths within the source code itself. All images are embedded in the binary data, and all third-party files were added using the Projucer.
I’m really not sure what the issue is. The two people who contacted me both tried separate DAWs that recognize VST3 plugins, and it either just doesn’t show up whatsoever, or it simply just says ‘error’.
I was not aware that the user needs to have JUCE, I was originally using a JUCE 7.0.something build but I just updated JUCE to the most recent build (8.0.8). Is the plugin binary the BinaryData.obj file in the Builds/SharedCode Folder?
I notice there is only one .vst3 binary. Is that for Windows or for macOS? You better specify that in your Readme and the Release info page. Although you can release your code under MIT, the whole project with JUCE 8 code shall be released under AGPLv3.
Some potential problems:
If it is for Windows, does MSVC runtime get static linked? BTW, JUCE 8 only supports Window 10 and later.
If it is for macOS, is it universal for x86_64 and arm64? what is the minimum target macOS version?
I went ahead and changed the README. I wasn’t aware of the AGPLv3 licensing but I’ve included it in the README (if I’m supposed to include it elsewhere, please let me know). I also thought that Macs don’t take VST3s in general so I was intending for it to just be for windows.
I found out what the issue was and you’re all going to laugh at me. I had been exporting the plugin on debug mode the whole time instead of release mode.
I want to put this here in case anybody in the future is struggling with the same issue and this forum post comes up:
Go in Visual Studio, and in the dropdown menu where it says “debug”, change it to “release”. That will make it export properly.
You still committed the plugin binary to your source tree. This is very bad practice.
You’ve now added, removed and re-added the binary thus putting it 3 times in your git history.
This is only going to inflate your repo size and is not sustainable. Use the Releases for spreading plugin binaries like every other project
Interesting project .. you could probably get MacOS builds (AU and VST3 targets) done simply enough by converting your .jucer file to a CMakeLists.txt file, using AI/ML .. I’ve found that Grok converts .jucer projects to CMake quite well.
But .. Those new’s in your processBlock() are a bit thorny! Might want to refactor that in your next release …
Especially without any corresponding deletes as far as I can see. But it also seems like those buffers aren’t even needed because it seems everything’s processed one sample at a time anyway.
Even with future delete’s, this is a big no-no for JUCE development… better to allocate the buffers you’ll need in your constructor and keep things purely pointer based in the procesBlock().
But anyway, nice work @briantxfazoli - keep improving the codebase, its a decent project.
…or in prepareToPlay(), if you need information about the sample rate and/or maximum buffer size you will need. Never allocate in the processBlock function (or anything that it calls).
