-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please bring back Linux support.. #25
Comments
Will have a think about it. Cutting releases is currently difficult and manual (both Windows and macOS have bespoke project setup steps that nuke each other if I regenerate either). Automating release management is hard to do legally due to VST2 licensing changes (it's end-of-life'd; no longer freely available). Maintaining dev environments on three OSes is difficult (running out of disk space, switching computers, keeping them up-to-date, remembering how to make installers or 32-bit distributions on Windows). All of these are solvable (except the licensing thing). the most sustainable way would be a "single cross-platform build system" (e.g. through CMake) and switching to compiling dependencies from source and statically-linking them. probably possible (not sure what CMake projects are like for macOS or Windows native apps). Requires a fair bit of effort. It's possible to ignore the general problem "how can releases be cut for all OSes automatically" and just figure out how to cut a one-off Linux release. This is probably not too hard; the default JUCE project build configuration would work with only a couple of tweaks (linker flags saying how to dynamically-link to libfluidsynth). But libfluidsynth has a whole conga-line of dependencies (like glibc), so there's a question of what the installation instructions should be and how to distribute it (where is the user supposed to get those libraries from, and where should they be installed to, and do any rpaths need rewriting). So, you can take shortcuts but there's existing friction that'd get in the way. Again, overhauling everything to build-from-source and use static linking would eliminate these bespoke steps and difficulty in distributing. |
looks like there's an open-source effort to provide a non-proprietary implemention of the VST2 SDK: it's a long shot, but if that works (completely and on all platforms and with JUCE's compiler): then that might provide a path to automated releases (i.e. without needing the end-of-life'd Steinberg VST2 SDK). |
Thanks for the quick reply and insights! I for one (and presumably others) would be fine with a stopgap Linux release for the time being and I realize VST2 is EOL but it is well tolerated in most popular Linux DAWs, if it didn't have any showstopping bugs I wouldn't even care if it missed all the regular point releases (something is always better than nothing..lol) at least until such time as you have something like a CMake cross build system set up. I'm happy to test compile it although TBH I'm no good with editing code but I've put in a lot of compiler hours in my day. |
I would like to feature Juicy SF plugin on: However I need all cross-platform binaries (Linux, Mac, Win). I agree with a one-off build would be great. Have you considered creating a GitHub CI pipeline? You can build a JUCE project cross-platform on GitHub CI. Here is an example I made: And an example for Projucer: |
Hi, Linux VST2 soundfont hosts are VERY rare, we'd love to have juicySF compiling on Linux systems again! In my own selfish little world I'd even like it to compile for 32bit systems, but hey, baby steps...baby steps
The text was updated successfully, but these errors were encountered: