9 ms·
I work for a small company that produces a DAW and VST plugins. Supporting Linux is a huge amount of work compared to Windows and Mac. The main issue is that '
by FigBug 8y ago
I work for a small company that produces a DAW and VST plugins. Supporting Linux is a huge amount of work compared to Windows and Mac.
The main issue is that 'Linux' is not a thing you can support. You have to pick the distros you want to support, and then once you've picked a distro, what versions you want to support.
And you need to use the C++ version that ships with that distro, so if you want to support old versions then the entire project is held back from using latest C++.
And distos aren't backwards compatible. ie when libcurl4 is released, they remove libcurl3. So you can't have one binary for Ubuntu 18.04 and 16.04.
So it means for every product, have a build for every distro / version combination you want to support.
So now the solution is AppImages where you bundle up your app with all dependencies like a container. Haven't investigated this yet, not sure it will work for plugins.
- chme 8y agoProprietary software on Linux is a bit of an alien there. But there is always static linking, is it not? (And now flatpak+snap+...)
- mitgraduate 8y agoWhy use not Electron? Take a look at vscode it has plugins and it seems to work everywhere.
- loa-in-backup 8y agoUnfortunately DAW and VST plugins are not something you can make in Electron
- mitgraduate 8y agoCan you please explain why?
- noselasd 8y agoBecause the plugins embeds into existing native applications and uses existing native SDKs.
- deleted 8y ago[deleted]
- fb03 8y agoAudio software has strict buffer/latency demands which usually cannot be guaranteed on interpreted language platforms. Doing audio synthesis with JS or any other interpreted language really is totally possible and has been done in a more or less serious way in several implementations and webtoys etc. But if you need extremely low latency and guarantees you cannot go that route, sadly.
- mitgraduate 8y agoYou can always write native extension in c++/rust/c.
- thecatspaw 8y agoso then why use electron as well if the majority of your code is going to be native anyway?
- fb03 8y agoexactly. the UI is the minority of the code. the main engine is gonna need to be implemented in some language which has strict guarantees about performance. also, not having a garbage collector that fires in a seemingly random way helps a lot too :)
- purplerabbit 8y agoIt's probably a decent way to package your program. And you can use all the glammy JS you want.
- loa-in-backup 8y agoThere are few reasons: - they most of the time run embedded in a DAW - they are usually computationally intensive themselves - they are meant to be instanced as far as memory/CPU can go ad to the third point: Music producers already require and use pretty powerful rigs: 32-128GB RAM is not uncommon, CPU as good as it gets. There's great benefit when you can run 100 instrument synthesizer instances parallel vs 14 instances - it's a difference between a differentiated orchestra and a rock band.
- deleted 8y ago[deleted]
- klodolph 8y agoElectron is basically Node+Chrome. There’s no way in hell it’s appropriate for writing VSTs.
- jcden 8y agoFriends don’t let friends use Electron
- loa-in-backup 8y agoSome binaries are meant to be linked statically
- mrspeaker 8y agoThe DAW isn't Bitwig is it? (just because your username has the same amount of syllables ;) If so, then PLEASE keep up the great work supporting Linux. I was only able to ditch my Mac a year ago because I switched from Ableton Live to Bitwig!
- FigBug 8y agoNot BitWig
- vectorEQ 8y agorenoise is also available on linux, great product works like a charm on linux :D
- fb03 8y agoalso, Renoise is frigging awesome. it is a blessing to be able to work with a different paradigm than piano roll and with such modern tooling (renoise supports vsts, rewire integration and whatnot), being essentially a supercharged tracker.
- EamonnMR 8y agoI've been meaning to pick it up, would you recommend any tutorials for figuring out how to use the tracker interface to sequence?
- erikb 8y agoI don't know why people say that. You don't support Windows XP and Windows 10 either with the same binary. In contrast to Windows you can provide or pay someone to provide libcurl3 if you want to continue to use it. MS will just say you can go F yourself. In contrast to Windows you can study the source code and write a wrapper that provides a central API point that you can use in your single code base. In contrast to Windows you can actually go there and provide patches. Even if the original authors won't merge it you can still use it via a fork etc. And last but not least I bet there are actually still people supporting and providing libcurl3 binaries to this day and you just need to google their package server and add 2 lines to your installer script (one to add the public key for that package repo and one to add the package repo to your package manager). PS: If you provide software for sizable amounts of people you need to provide 1-3 out of 3 reasonable Distros: Debian, RHEL, Suse. Even if you just provide one most people can deal with it thanks to VMs or docker.
- FigBug 8y agoFor a 32 bit version, a single binary compiled in VS2017 could support XP to 10. For 64 bit, a single binary supports Vista to 10. In my experience, MS doesn't say go F yourself. They go to extreme lengths to keep old software working.
- youdontknowtho 8y agoThis is a common misconception. Microsoft is a little insane about backward compatibility. You can target versions of Windows with a single binary from the latest all the way back to unsupported OS's like XP. There are lot's of companies that take advantage of this. It's one of the reasons why MS has so much trouble moving app developers to the new hotness, even if it's safer, faster, or whatever. Because of that the new hotness doesn't get enough traction to support continued development and they sunset it early which draws even more ire from people.
- 21 8y agoI use a Windows audio software binary last compiled in 1997, for Windows 95. It still works just fine on Windows 10 64 bit. That's 20 years of backward compatibility.
- 8y ago
- vectorEQ 8y agobiggest problem with plugins imo is that often they don't support the same things as the daw does so usually come without linux installers (even though the code runs just fine on linux... )
- chrisseaton 8y ago> So now the solution is AppImages where you bundle up your app with all dependencies like a container. But isn't this what you're doing with Windows? No version of Windows comes with libcurl (as far as I know) so you put the DLL in your application directory. It's no different.
- FigBug 8y agoOn Windows, I use the Windows API for downloading files. I don't need to worry about curl. On Linux, I could have statically linked curl, but didn't realize it was going to become an issue. Ubuntu 18.04 was released and curl3 was removed, so that means our software that was working was either automatically removed by the package manager or it started crashing.
- angry_octet 8y agoYou don't have to statically link, you can use LD_PRELOAD to point to local versions of all libraries. It isn't optimal, from space/security perspectives, but it works. You can use the local libs first or last in the path.
- Spivak 8y agoYou don't even have to do that. When you compile your binary you just need to set the rpath to your own directory of libs and they will be search automatically and fall back to the system if missing.
- angry_octet 8y agoLast time I looked the rpath is a static absolute path, which is inconvenient if you want to install the libraries elsewhere. The automatic fallback to system libraries can also lead to mysterious problems.
- Spivak 8y agoThe linker recognizes a variable that expands to the location of the binary so you can use relative paths. ${ORIGIN}/lib will be the relative library path.
- linuxftw 8y ago> And you need to use the C++ version that ships with that distro, so if you want to support old versions then the entire project is held back from using latest C++. > And distos aren't backwards compatible. ie when libcurl4 is released, they remove libcurl3. So you can't have one binary for Ubuntu 18.04 and 16.04. Release the source and the community will help you with many of these issues.
- hkt 8y agoI concluded ages ago that no substantial applications should be integrated into an operating system. Dynamic linking if you're building something portable is just an awful idea because of how much variety you'll inevitably have to support (or choose not to support). Some people have written about AppImages, this also applies to FlatPak and similar techs too. Isolating anything more complicated than a command line tool is the way forward and the tech exists. Not using isolation this way is a recipe for pain, whether it be on the desktop or the server (or the phone). It depends how the plugins are loaded - it'd be great if they could use sockets so that AppImages were viable. No idea myself, though.
- FigBug 8y agoThey are VST plugins and the are dynamic libraries. Call dlopen and call a specified function.
- singron 8y agoConfusingly, you can statically link a dynamic library (i.e. the dynamic library includes all its dependencies statically instead of recursively depending on more dynamic libraries). You can even link it in such a way that the dynamic library gets its own version of each dependency regardless of what the main executable is linked to (otherwise the main executable's links could override yours). I did this once with a ruby gem that had particular c++ dependencies that kept breaking when the build machine had different library versions than the production machines. If you aren't integrated directly with the development of a linux distro, it's best not to use their packages as runtime dependencies, since they really only consider their own use before changing things up.
- plq 8y ago> And distos aren't backwards compatible. ie when libcurl4 is released, they remove libcurl3. So you can't have one binary for Ubuntu 18.04 and 16.04. If you don't want to depend on the libcurl provided by the OS, ship your own. If you don't want to depend on the glibc provided by the OS, ship your own, with your own dynamic linker. readelf -n <your binary> will tell you the oldest kernel that will run your stuff. Put that in the requirements document. Write a bash script that sets LD_LIBRARY_PATH correctly and make sure that's the main entry point to your application during deployment. You're set.
- gdy 8y agoCould someone explain why this is downvoted?
- angry_octet 8y agoSelf-important idea police?
- CyberDildonics 8y agoThat is completely ridiculous. Pointing out that statically compiling dependencies or shipping them with a game can solve many so called compatibility problems is directly related to games working on linux.
- mackal 8y agoIt is also the solution they currently use on Windows ... And what games are doing on Steam that support Linux. I won't comment on shipping your own glibc, because that probably could cause issues.
- _wmd 8y agoIt's a wonderful idea - on paper, but all that's needed is for one of the many mandatory deps for running a GL program to link against the system libcurl or any other replaced dep and you're back in Crashville again, population 1 - cloth-eared developer
- vetinari 8y agoWhy not pick a "distribution" like org.freedesktop.Platform/18.08 (i.e. pick a flatpak runtime) and support that? It runs on all desktop distributions. Updating supported flatpak runtimes is then on your leisure, not on their release cadence.
- curt15 8y agoHow long are flatpak runtimes supported? What is their update policy?
- vetinari 8y agoThe runtimes are not locked down, anyone can publish theirs (under their domain name, ofcourse), so it depends on who publishes it. For the freedesktop one, they have following policy[1]: - When a new stable release release is done, the changes on that branch will only be: - security updates - stable releases (tested carefully); no ABI breaks / API build breaks. - we will try to keep updating that branch as much as we can - We release a new major release every year, only if: - There is a ABI break - There is a "API build" break (apps might not compile because new major releases of important packages (GCC)) - Looking at the GCC and other major project cadences, this is likely going to happen annually. - We only maintain the current stable release and the previous one, this means: - Stable releases get 2 years of security updates - We maintain maximum 3 releases at any given time: - Development - Stable - Old stable [1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/release https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/rel...
- zanny 8y agoThat sounds like more something to blame the Debian family over than the whole ecosystem. I might be running "bleeding edge" on Arch but I can still depend on and use libcurl3 with the libcurl-compat package. I maintain about two dozen software packages in the AUR, including some really old stuff like the Heretic 2 Linux release from 1999 and RBDoom 3 BFG which has a boatload of dependencies. Breakages are extremely rare for the average package even with the rolling release and generally any breaking change in a common library will see the legacy version hang around since stuff will still depend on it.
- klodolph 8y agoI don't think it's Debian, because Debian tends to have compatibility packages for old versions too. For libcurl there's libcurl3. It depends on the package, of course.
- pantalaimon 8y agoOnly for so long - try installing qt3 on a recent Debian or Ubuntu.
- klodolph 8y agoI might compare qt3 to Silverlight or ActiveX.
- zanny 8y agoI don't have a Debian machine to test it on but a casual search finds qt1-3 in the AUR on Arch. Of course building the whole GUI suite would be a bit annoying but its better than nothing if you have some really old software that depends on it.
- copperfoil 8y ago> You have to pick the distros you want to support, and then once you've picked a distro, what versions you want to support. What if game developers release the game's source code and let community developers help with porting to different distros and platforms? The game's assets can remain paid. For example, Doom has been ported to pretty much all platforms, and it's up to maintainers to ensure compatibility. I guess at this point it becomes a partly open source/free software game. I'm aware this may not align with current business practices.
- CyberDildonics 8y agoWhy wouldn't you just create a statically linked binary?
- jcelerier 8y agoAFAIK you can't call dlopen from a static binary, and if it's a DAW you have to support dlopen in order to open the VST plug-ins
- jcelerier 8y agoI am developing an open-source DAW with Qt (https://ossia.io https://ossia.io), to solve the problem you mentioned I used AppImage with great success - of course you have to ship all your libs, but that's what you have to do on macOS and Windows too anyways.
- FigBug 8y agoDo you ship any plugins? Do you do a separate AppImage for each plugin?
- jcelerier 8y ago> Do you ship any plugins? I used to but I'm switching to a different model > Do you do a separate AppImage for each plugin? no, they are just loaded as .so / .dll / .dylib in the ~/Documents/score/addons folder. They can't have further dependencies though.
- EamonnMR 8y agoMusic software's dependance on Windows is such a mess. Tons of cool plugins are stuck as windows-only VSTs! I was really hoping that Propellerheads would use the fact that it can ship on any platform to ship Reason and all associated REs on linux or in-browser, but instead they gave in and added VST support.
- sneakernets 8y agoA historical lack of low-latency audio is likely why you haven't seen many music software releases on Linux. For years, you had to have a custom kernel to get "decent" performance.
- lj3 8y agoCan confirm. I fondly remember late nights hacking the Gentoo kernel so my college radio station could reliably live stream shows via icecast and darkice.
- vortico 8y agoI work for VCV, which also ships for Linux. I don't find it an issue at all, since the build system is a Makefile supporting Mingw64/MSYS2 on Windows, Mac, and Linux. We statically link everything except glibc, which we've decided to dynamically link to glibc 2.23 (meaning that Ubuntu 16.04 is the oldest we support). We've had no problems with this approach, although the disadvantage is that we have to use an old version of GCC to compile the software, since I haven't figured out a way to make a new GCC version produce binaries which link to old glibc. No need for containers or anything, just make a mostly-static-except-for-glibc binary.
- jcelerier 8y ago> the disadvantage is that we have to use an old version of GCC to compile the software, since I haven't figured out a way to make a new GCC version produce binaries which link to old glibc. I personnally compile with latest GCC or LLVM on centos 7, this way I can use the very latest C++ standards with a venerable glibc
- deleted 8y ago[deleted]
- dominotw 8y agobitwig?
- dhogan 8y agoMusic Production is one of the last things I keep Windows around for. That sounds like a cool job though.