Most commercial software only supports Ubuntu officially, and everyone else has to figure out how to get them to work.
You can’t expect a developer to support 5 or more distributions that are responsible for less than 5% (and that’s generous) of their revenue.
Personally, I’m happy to have a Linux version at all, and I’m not going to make any demands to have it open sourced.
Besides, even with open source apps, you’re usually months or even years behind the current release in your distribution. That’s why Snap et al exist now.
If the downloads page said “Ubuntu” and not “Linux”, and I hadn’t paid 80$ for it, I’d agree, but it says Linux and I’m a paying customer.
It’s well within the realm of reason for me to request that Vital works on other popular distros, when I know the solution isn’t too complex to pull off either. Besides, it would only be good for business if it worked everywhere.
If you use Ubuntu and it works on your system, good for you. This bug report doesn’t affect you.
This bug report affects me because I’m using Manjaro and I have to click to get past the login screen every time.
But I’m able to read, so I saw that only Ubuntu is supported on the sales page, so I don’t make irrational demands. The download page also says Windows, but you wouldn’t expect it to run on XP, would you?
It also affects me because dev time is limited and if it is spent on supporting hundreds of distributions, less features will be developed as a result.
I think the supported OS should be stated more clearly. If it does not work on some versions of Windows, this should be stated, similarly for Linux and MacOS. Also which platforms are supported, e.g. Ubuntu x64 is supported but not x32, arm, etc. I feel it a fair request to make the supported systems clear on the sales / download page. I also would like to see minimum system requirements listed.
With regard to supporting other platforms or distros, that may need to wait until there are developer, testing, release resources available. (It isn’t available on any platforms I currently run .) One can’t expect more than 24 hours in any one day .
But at least it says Ubuntu, just not which CPU architectures.
Generally, it’s a good idea to download the demo to see if it works or not. It’s impossible to predict compatibility with all the hard and software combinations out there.
For the issue at hand, that won’t help. There is a conflict with the libraries that Ardour/Mixbus binaries use. Specifically /opt/Ardour-*/lib/libglib-2.0.so.0.
System-wide libsecret-1.so.0 also depends on glib, but require a different version of it.
@tytel: What does Vital use on Windows and macOS instead of libsecret?
Many GNU/Linux distributions do not want to re-link all applications when a shared library changes. It makes perfect sense for standalone applications, but plugins are special. In fact they should always be statically linked (except for libc, libX11, and lib/server interfaces), and not expose symbols. KXStudio for example statically links all plugins.
This is so that plugins cannot conflict between each other.
Tech Details
Say you have one plugin linking against system-wide libaubio.so.2 and another using libaubio.so.3. They have conflicting APIs so many distros still bundle both for applications to use them. But when loading the plugins there will be a symbol conflict. Same for libavresample, or QT4/Qt5…
By induction this also include the host (which may use libraries), but the host is a singleton.
To avoid ABI conflicts, the only option other than statically linking is to process-separate plugins (like Carla does). But many hosts (incl. Ardour) do not do that: https://ardour.org/plugins-in-process.html
Ah this is pretty useful, thanks. I’ll have to revisit this when I’m tweaking the builds.
Mac and windows both have some included things like libsecret in the OS. Vital uses the keychain on Mac but I can’t remember what I’m using on Windows.
I’m on Fedora 34, and Vital wasn’t working for me due to the libcurl-gnutls issue, but I found a COPR package for it, and now Vital works. However, sign-in doesn’t work at all. It could be related, but it doesn’t give any output in the console.
Static linking would be really nice for compatibility, if it’s not much trouble
@Tytel i think the best way to support other Linux Distros is to ship a Flatpak version. Currently exist all most all Audio Plugins as Flatpak also you Helm Synth is already as Flatpak version available
A Vitalium Version exist also aready as Flatpak Version but unfortenly it have a strange bug but maybe we can figureout it together.
pls checkout this Link:
I still searching for the Helm Github link but i cant find it i just know it exists and works greate AS flatpak
@Tytel Hi Matt, I’d love to work with Vital in Ardour on Linux, I wonder if you had time to look at the issue of statically link libsecret-1 within the Vital VST … Thanks again.
This is orthogonal to the issue at hand, it’s just a different means of distribution.
While you could include the relevant shared libraries in the flatpak, there will still be conflicts once loaded into the host where the ABI can conflict with other plugin or host libraries.
So either the plugin needs to be statically linked, or compiled with the same dependency stack as other plugins.
Yea ok i think static linking is the best solution U-He dose this also and works perfect on all Distros i used As a workaround on Fedora i currently using Vitalium
I installed the beta pre-release 1.5.5, and Ardour failed to detect Vital. I had to manually re-scan the plugin. A recent thread on the Ardour issue tracker points to this discussion.
I also tried installing Vital 1.0.7 and get the following errors in Ardour 7.1.0 on Ubuntu 22.04
[ERROR]: Could not load VST3 plugin '/usr/lib/vst3/Vital.vst3/Contents/x86_64-linux/Vital.so': /lib/x86_64-linux-gnu/libsecret-1.so.0: undefined symbol: g_task_set_name
[WARNING]: Failed to add Synth Plugin to newly created track.
[ERROR]: Could not load VST2 plugin '/usr/lib/vst/Vital.so': /lib/x86_64-linux-gnu/libsecret-1.so.0: undefined symbol: g_task_set_name
[ERROR]: LXVST: cannot load module from "/usr/lib/vst/Vital.so"
My system has libsecret-1-0 version 0.20.5-2 installed.
.) One can’t expect more than 24 hours in any one day 
.
As a workaround on Fedora i currently using Vitalium