The linux DAW thread

[dan_flash]

Also worth noting that a lot of Linux VSTs are available on developers' websites and are often just .so files in a zip. In such cases, simply download -> unzip -> copy to your VST folder (eg. usr/lib/vst).

With the above in mind, avoiding Flatpak stuff is fairly easy I think.

[Largos]

With the plethora of installers and drm "hubs", I guess people lose sight of the fact that plugins are just files you can copy paste anywhere on your system.

[glokraw]

utopian

Where does this obsession with container software come from?

It's because some people want "commercial" "pro" software to be on Linux to provide some kind of validation. They see Flatpak as a vehicle for this because it's a distro agnostic packaging system. Never mind the technological downsides of using it for audio production, that won't be addressed because they are inherent in the design and philosophy of a container app.

I'm not obsessed by containers, and don't need them. I use commercial software in linux when it's the best tool for a given job, including ease of use, and the time needed to finish a task. Validation has never entered my thinking. There's plenty of great software that doesn't have a price tag, which I use on a regular basis. Happy with the best of both worlds.

[glokraw]

Also worth noting that a lot of Linux VSTs are available on developers' websites and are often just .so files in a zip. In such cases, simply download -> unzip -> copy to your VST folder (eg. usr/lib/vst).

With the above in mind, avoiding Flatpak stuff is fairly easy I think.

I always move installed audio plugins out of any /usr path, to a /home/me location. And would never copy the many simple .so plugin files to a /usr location. Pointless work, and without musical benefits.

The only thing I know about flatpack and it's competitors, is that I don't need them. Fine by me if lots of people do, just don't mess things up along the way, and don't block remedies to overturn their results, should that be desired. Dependency hell is not cool.
Cheers

[dan_flash]

I always move installed audio plugins out of any /usr path, to a /home/me location. And would never copy the many simple .so plugin files to a /usr location. Pointless work, and without musical benefits.

How come? Is there a drawback to sticking them in /usr instead of /home, for example?

[audiojunkie]

I always move installed audio plugins out of any /usr path, to a /home/me location. And would never copy the many simple .so plugin files to a /usr location. Pointless work, and without musical benefits.

How come? Is there a drawback to sticking them in /usr instead of /home, for example?

There's a few reasons to prefer this path. A few that come to mind:

It's simply an easier place to manage plugins. You can back them up and not have to reinstall them every time you reimage. It's also an easy path that one can give to the DAW to find plugins.

If one were using Bitwig with Flatpak packaging, the /usr path would not be able to be seen by Bitwig, whereas Flatpak sees what's in the /home directory.

[dan_flash]

Fair enough, seems logical I suppose

[mryan4]

utopian

Where does this obsession with container software come from?

Part of the magic of Linux, for me at least, is how easy it is to just open package manager, search, install, done. So much easier than Windows (go to website, find download link, probably have to give my email or create an account, find downloaded installer exe, click through options to install, making sure that I'm not installing any junk in the process).

Also, although I understand the appeal of managing my plugins in my own user folder (I used to do that kind of thing with all my files), now, with a full time job and family obligations, I just want my OS to manage that. I don't care where things are installed. I trust the package manager/deb file to put things in the right place, and 99% of the time, they do. So far, with the exception of VSTs, Flatpak has been spot on with everything I've installed this way, hence the wishes for it to work this smoothly with VSTs as well.

Yes, I'd have to reinstall things if I reinstall the OS, but I'd probably only do that if something breaks, and even if so, I'd see it as a chance to clean up much of the stale programs and VSTs that I downloaded but rarely use. I'd just reinstall the few that I use frequently, and then back to music. I generally only use a few "workhorse" synths for nearly everything, but I can understand this approach may not work for someone with tonnes of synths to reinstall.

Different things work for different people, and that's one of the biggest strengths of Linux, that both methods (should) work. Perhaps "utopian" was too strong a word, but I do hope the day comes when I no longer need to download anyone from anywhere except a trusted package repo, and this same repo will take care of maintenance and upgrades as well, which means more time for music.

[glokraw]

I'm all for new and improved, as long as it no effect at all on tried an true

('new' is easy to define, 'improved' varies on the widely diverse desires and needs
of musicians. Freedom of choice is the big fundamental (even in San Antonio )

[Largos]

Part of the magic of Linux, for me at least, is how easy it is to just open package manager, search, install, done. So much easier than Windows (go to website, find download link, probably have to give my email or create an account, find downloaded installer exe, click through options to install, making sure that I'm not installing any junk in the process).

That's not a flatpak specific advantage, just a feature of using package managers

Also, although I understand the appeal of managing my plugins in my own user folder (I used to do that kind of thing with all my files), now, with a full time job and family obligations, I just want my OS to manage that. I don't care where things are installed. I trust the package manager/deb file to put things in the right place, and 99% of the time, they do. So far, with the exception of VSTs, Flatpak has been spot on with everything I've installed this way, hence the wishes for it to work this smoothly with VSTs as well.

Again, I think you are confusing the convenience of a package manger per se with flatpak. flatpaks and deb files are different things. The reason flatpak exists is so programs can use a specific dependency which may not be included with the operating system. This isn't a real problem for plugins and as the easiest way to use plugins is just to move them to a set folder like /usr/lib/vst or ~/.vst then it's unlikely it will ever change.

Yes, I'd have to reinstall things if I reinstall the OS, but I'd probably only do that if something breaks, and even if so, I'd see it as a chance to clean up much of the stale programs and VSTs that I downloaded but rarely use. I'd just reinstall the few that I use frequently, and then back to music. I generally only use a few "workhorse" synths for nearly everything, but I can understand this approach may not work for someone with tonnes of synths to reinstall.

Different things work for different people, and that's one of the biggest strengths of Linux, that both methods (should) work. Perhaps "utopian" was too strong a word, but I do hope the day comes when I no longer need to download anyone from anywhere except a trusted package repo, and this same repo will take care of maintenance and upgrades as well, which means more time for music.

How hard is keeping up to date a "few workhorse synths" whichever way it is?

[mryan4]

Yeah, to some extent I am confusing package manager vs. Flatpak, but when I searched in my package manager for common Linux synths (things like Surge XT, Dexed, Vital, etc) the only thing that came up were Flatpaks. Adding KX Studio repos helped a bit, but many of the synths there were still missing or outdated compared to the Flatpaks. Is there a more up to date repo somewhat that I'm missing?

It's not THAT hard to drag some files around or to manually check websites for updates, but if my package manager can do these things for everything else installed on my system regardless of installation method, then why should synths be any different?

[audiojunkie]

Most plugins are available either through the open source developers github, sourceforge, or gitlab site, and most closed source developers plugins are available through their web site. For your Reaper DAW that doesn't use flatpak, there are lots and lots of high quality plugins. If your DAW is using Flatpak, you have to use whatever is provided on Flathub.

For example, these are just a few of the available high quality open source packages available:

https://surge-synthesizer.github.io/

https://www.thewavewarden.com/odin2

https://yoshimi.sourceforge.io/

https://github.com/sfztools/sfizz/releases/tag/1.2.0

https://drumgizmo.org/wiki/doku.php

https://lsp-plug.in/

https://www.airwindows.com/

http://x42-plugins.com/x42/

and on and on and on and on........

Get the your binaries from these locations, and install them easily with Gdebi:

https://itsfoss.com/gdebi-default-ubunt ... re-center/

This process is at least as easy as Windows.

[glokraw]

Glad you added the "and on and on and on and on........"

The instrument/effect creators in the linux music scene are mostly on their own time, and their own dime. Without regular corporate paychecks from sales of their creations, they are somewhere in the workforce at large, and hopefully well paid.

It takes time to package their software for distribution, or to create binaries that will work in most linux systems. Time they can rightfully say, they don't have. The covid fiasco has proven that family, workplace, and social time, is crucial to happiness and success (mental and physical health in general)

If there were a consensus among audio/video devs on which libs and gui toolkits etc to use, it might be easier, but consensus is not a strength of linux systems, while wild diversity is. The ability to conceptualize a new and better way, and then code it, is pretty amazing.

Most of the best software can be compiled, with devs available to sort out an odd result. I've never needed to compile anything, as the very latest versions show up in some useful form soon enough, and the previous releases are always more feature-rich than I am skills-rich, so I just keep recording during any short wait.

[audiojunkie]

Yeah, to some extent I am confusing package manager vs. Flatpak, but when I searched in my package manager for common Linux synths (things like Surge XT, Dexed, Vital, etc) the only thing that came up were Flatpaks. Adding KX Studio repos helped a bit, but many of the synths there were still missing or outdated compared to the Flatpaks. Is there a more up to date repo somewhat that I'm missing?

It's not THAT hard to drag some files around or to manually check websites for updates, but if my package manager can do these things for everything else installed on my system regardless of installation method, then why should synths be any different?

Flatpak is a package manager too. The key differentiation is between the distro's default package manager, that uses the standard DEB, RPM, etc, and the "Sandboxing" package managers, such as Flatpak, Snap, or Appimage. They have different purposes, but they are all package managers.

The Debian family of distros installs DEB packages through tools like Apt-get, aptitude, etc
The Fedora family of distros installs RPM packages through tools like YUM (outdated) or DNF
The Arch family and OpenSuse family of distros does the same each with their specific packages and tools. These are all the tools that are used for installing binaries from each distro's default repository. In general (with some exceptions), binaries compiled and packaged as DEB files won't work on Fedora distros, and compiled binaries packaged as RPM files won't work on Debian distros. The same for most other distros--you generally use the binaries compiled for your specific distro and using your distro's specific package manager.

This, however, brings problems to developers. I'm over simplifying, but in general, to provide quality support, they have to compile for each and every distro they support, which makes for a lot of work. They generally don't want to do it. That's where "sandboxed" package managers come in. These managers maintain a separation between application libraries and system libraries, to prevent dependency hell. Sandbox package managers store all the libraries that are needed to run the application in a special sandboxed file system. Everything needed to run the package is there. The main benefit of this, is that the developer only has to compile the software once in this special sandboxed format, and it should run on any distro that supports that format--package once use everywhere.

So, in essence, they are all package managers, but for different purposes. Each has their pros and cons. Unfortunately, Flatpak sandboxing prevents the flatpak packaged application from seeing any folder outside of what it provides or the home directory. If you can get a plugin installed in your home directory, it should in theory work. There are no such restrictions for DAWs not using a sandboxed package manager like Flatpak. So, in general, when using flatpak, it's best to use flatpak plugins (and those plugins that work in your home folder). For everything else, you are out of luck until the industry decides to adopt Flatpak packaging.

However, Windows has always had the user download the plugin from a site, and then install it. Doing this through the distro's local package manager is the same, and if you are using a Debian derivative like Ubuntu, you can use a GUI-based tool and click on the plugins in DEB format and let the system install them. It's essentially just as easy as with Windows. It's just new for people so they feel uncomfortable with it at first.

The key that I think you are missing, is that instead of just using the default repository of your distro, you can go to the developer's sites, download the packages, and install them with your distro's default package manager (like I mentioned in my post above).

I hope this helps make things clearer.

[glokraw]

snip... binaries compiled and packaged as DEB files won't work on Fedora distros, and compiled binaries packaged as RPM files won't work on Debian distros...snip

The linux command 'alien' can convert between and/or install .deb in rpm systems,
or .rpm in deb systems. While various distro file-system paths may cause issues with
complex packages, simple audio tools and plugins should not be a problem when path uniformiy exists, or is created.

Things have improved much in recent years, but if there's no alternative, alien can offer
a nice last-ditch attempt. Thanks for the nice overview of the current situation
Cheers