search

Birch-san / juicysfplugin

Audio plugin (e.g. VST, AU) to play soundfonts on macOS, Windows, Linux
GNU General Public License v3.0
225 stars 29 forks source link

Please bring back Linux support.. #25

Open AVLinux opened 3 years ago

AVLinux commented 3 years ago

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

Birch-san commented 3 years ago

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.

Birch-san commented 3 years ago

looks like there's an open-source effort to provide a non-proprietary implemention of the VST2 SDK:
https://github.com/pipelined/vst2

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

AVLinux commented 3 years ago

@Birch-san

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.

kmturley commented 2 years ago

I would like to feature Juicy SF plugin on: https://studiorack.github.io/studiorack-site/instruments

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: https://github.com/studiorack/studiorack-workflows/blob/main/.github/workflows/juce.yml

And an example for Projucer: https://github.com/studiorack/studiorack-workflows/blob/main/.github/workflows/projucer.yml