Birch-san
commented
1 year ago hey, thanks for trying this out 🙂
what CPU architecture are you building for? For macOS, I did find that FL studio's plugin validator gets false-negatives on verifying ARM-native JUCE plugins. I had to built it as a Universal Binary in order to pass validation, because I think it only considers x86 plugins valid.
the other thing that might be needed for a macOS distribution is code-signing? not sure what error you'd get and when though.
but I think the most likely thing… did you build it in one container, copy it elsewhere, validate it in a different container?
because that's a 3.31MB .vst3 file. I bet you're dynamically-linking, since a statically-linked distribution (i.e. all libraries burned into one file) would be 12.1MB as a release build.
if you're dynamically-linking: I bet you've linked to a .dylib which doesn't exist in the container which is vaildating it.
try printing the load commands to see which dylibs it's linked to: otool -L juicysfplugin-mac.vst3
are those libraries actually on the computer that's doing the validation?
if that does turn out to be the problem: here's how to make a portable distribution of juicysfplugin:
https://birchlabs.co.uk/blog/alex/juicysfplugin/synth/cpp/2019/01/05/a-soundfont-vst-for-macos.html
you could try debugging the load-time linker:
DYLD_PRINT_LIBRARIES=1 validator "juicysfplugin-mac.vst3"this will print every dynamic load command it attempts. I think. if there's failures, it might tell you.
Would this be a feature you would be interested in using? I can submit a PR?
CI would be nice, but I fear that I have a lot of requirements that are hard to meet. I want distribution/installation to be easy on all platforms. I thought static linking was the solution to this, but it's super hard (I failed to finish getting it working for Linux… just too many libraries to compile-from-source). so maybe for Linux the answer is distribution via a package manager. but that sounds like a lot of work too…
the best answer for Linux would probably be a statically-linked image built on muslc. I think this would work on every Linux distribution. so it'd make sense to do the work in an Alpine Linux image, which gives you access to muslc-based libraries.
for macOS… dynamic or static linking could be fine (I've done both in the past), but it needs to be a Universal Binary in order to pass FL Studio's plugin validation. nobody distributes Universal Binary libraries of fluidsynth and its dependencies, so that adds some complexity in terms of automating it. it probably also means you can't use a solution based on brew, because you wouldn't be able to express a dependency on the fluidsynth they publish.
I don't have a business Apple Developer account, so I believe I cannot produce a signing key for CI to sign macOS artifacts. this means anything built by CI would be hard for users to install.
VST2 cannot be done in CI (I cannot distribute the Steinberg VST2 SDK). I dunno whether anybody still needs VST2 though.
Windows is the biggest problem. if you dynamically-link, you need to put the .dlls somewhere. there's not really good options; you can't put them next to the VST2 dll, because the DAW requires that every dll in the VST2 folder be a VST2 plugin.
for all platforms, I'd want licenses of every dependency included in the distribution.
I got the Windows build working pretty well -- it's a Dockerized, Linux-based cross-compiler which builds a statically-linked Windows binary via LLVM-MinGW toolchain:
docker build . -f win32.Dockerfile --tag=llvm-mingw
docker run -it --rm --name llvm-mingw llvm-mingwhttps://github.com/Birch-san/juicysfplugin/blob/master/win32.Dockerfile
I tried to extend the Docker image to do an even more ambitious cross-compile (target 32-bit, 64-bit, ARM, x86, Windows, Linux, do everything with static linking):
https://github.com/Birch-san/juicysfplugin/commits/linux
but I didn't finish getting Linux working. tried for weeks but static linking is just too hard. dynamic linking probably an easier way to do it, but then you need to solve "well how will the user get or install the libraries it depends on".
a big reason why I went for a solution based on Docker — instead of GitHub CI — is that it also solves the problem of "how do I build the artifact on my developer workstation", for any host or target platform.
so, all-in-all it's a worthy cause but it's very hard. I think shortcuts can be taken (i.e. dynamic linking) but then it creates a distribution/installation problem instead. handling issues is very hard when there's no guarantee that the user installed it correctly. so I'm not sure there's a good option here.
kmturley
I spent some time trying to build your plugin with the following changes:
The resulting file is:
https://github.com/studiorack/juicysf/blob/master/.github/workflows/release.yml
Pipeline and jobs:
https://github.com/studiorack/juicysf/actions/runs/2976408057
However the generated binaries are corrupted. When I try to validate them with pluginval I get:
And same with Steinberg validator:
Where I am going wrong with my build commands?
Would this be a feature you would be interested in using? I can submit a PR?