Skip to content
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

Open
AVLinux opened this issue Jun 22, 2021 · 4 comments
Open

Please bring back Linux support.. #25

AVLinux opened this issue Jun 22, 2021 · 4 comments

Comments

@AVLinux
Copy link

AVLinux commented Jun 22, 2021

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
Copy link
Owner

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
Copy link
Owner

Birch-san commented Jun 22, 2021

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
Copy link
Author

AVLinux commented Jun 22, 2021

@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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants