Ardour as Snap or Flatpak

Just wondering, if there ever will be a flatpak or snap from Ardour?

The problem with either is that plugins also need to be inside the flatpak or snap. So 3rd party plugins cannot be used [1].

Likewise with JACK, the jack server is a system-wide application, sandboxed applications cannot use it. pipewire.org does address this for flatpak.

The official builds from http://ardour.org/download.html are also self-contained, just like a flatpak or snap they include all dependent libs, but unlike those it integrates nicely with any existing system.

So there is no benefit from packaging it as a snap or flatpak instead. Perhaps that will change someday…


[1] flathub.org offers an ardour build, and also bundles plugins so that they can be used. However this only works for plugins where the source code is available or ones with dedicated flatpak bundles.

1 Like

Ty for your reply. I see the problem for “not daily routine apps” with its sandbox restrictions.
For me it’s hard to check the pages for updates in a routine and I’d love to get Ardour officially from any repo.

If you’re just trying to get the latest version of Ardour, you could try using a 3rd party repo system like Nix or Homebrew. They’re particularly useful for ditsros like Debian Stable that end up running quite old versions of software towards the end of their lives. I use Nix personally and have found it to be ok so far.

:thinking:

Or one could just make a minimal donation and get the official Ardour bundle that already solves every problem presented by different Distros, Plugin locations and Audio servers… Unbelievable how difficult people will make things to literally save a dollar… :roll_eyes: How many times does a wheel need to be reinvented?

3 Likes

You can pay and still use repos for comfort if it’s possible (like 99,9% of all the software on linux). At least that’s my way.

For me it’s hard to check the pages for updates in a routine and I’d love to get Ardour officially from any repo…

Doesn’t ardour inform you if there’s an updated version available, when you start it? (or did I imagine that…) In which case I can’t think of a reason to not use the ardour.org builds.

1 Like

Is that how I’m expected to install and manage Ardour on AVLinux?

I can think of a few, but the most compelling reason to use package managers is that they make it much easier to automate installation, which is particularly helpful if you ever need to reinstall your OS.

That’s a pretty cynical conclusion to jump to without any evidence. Not that it’s any of your business, but I pay a monthly subscription to the Ardour project.

Getting back to the constructive part of this discussion, I’d just like to clarify what I said above about nix:

I meant that with regard to applications in general, not Ardour in particular. I don’t actually use Linux for audio production, so consider Nix to be a suggestion rather than a recommendation.

Absolutely! AVL ships the official bundle and encourages people to update with official bundles. However there is the option to self-build as well as AVL comes with a full build environment of the Ardour dependencies (it is possible some new dependencies may need installing as Ardour’s needs evolve).

Ok, well that’s an atypical way of managing software on Linux. Most people are going to expect to apt full-upgrade and be done with it.

It’s an “atypical” way of managing software that is best distributed by the Linux distribution.

But there’s lot of software out there in the world that doesn’t work this way.

Games. Oracle. Even Firefox would prefer that you run their official builds rather than the distro version. Almost all audio plugins from commercial developers.

We decided long ago that we could not possibly create distro-specific packages for every version of every distribution. We also decided that we were not going to “prefer” a handful of distributions for “special treatment”. So we came up with a way to create a distro-agnostic package that could be installed on (almost [*]) any Linux distribution. That’s what we distribute, and the only version we can support since its the only version where we control the build process.

[*] NixOS is the one exception, because they played games with the runtime linker in ways that break the approach that works on literally every other distro.

1 Like

Perfectly reasonable. I wouldn’t expect an open source project to provide anything other than the source code and a Makefile.

But of course other people are going to take it and make it easier to install on their platforms. That’s the whole point of using free software!

Indeed. And if everyone got the build process right, maybe I’d never have gone down this route. But building Ardour correctly is non-trivial, and many (most?) distributions get some part of it wrong. This is why we can’t really offer support to distro builds.

If I’m supposedly providing something unique and beneficial with a lot of the ‘inside information’ all figured out ahead of time how could I provide anything BUT the actual build of Ardour that is going to allow the User to work professionally and also get proper and full support from it’s developers?

You can apt-get Ardour in AV Linux also of course but it will not be the most recent or a version that gets any support. Taking a Distro and putting guitar wallpaper on it and just providing an unsupported Deb is not going to cut it, as Paul said Ardour is a unique case and it requires unique presentation.