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.
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.
ā¦
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ā¦ How many times does a wheel need to be reinvented?
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.
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.
We decided long ago that we could not possibly create distro-specific packages for every version of every distribution.
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!
But of course other people are going to take it and make it easier to install on their platforms.
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.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.