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 .
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.
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.
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
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.