…but I have no workaround for libsecret, and it shouldn’t be necessary anyway.
Statically linked libraries is an absolute must for Linux, it’s the best way to make apps compatible across distros.
@Tytel is this change something we can expect soon, since it’s a “blocker” issue? I understand the amount of bug reports might be a little crazy right now, so I’d understand perfectly if this would take a while. As long as it gets done, I’m a happy customer
No, the workaround only gets me past the first error and onto the next one.
VST and LV2 both exhibit the same behaviours.
I think the issue is that this plugin was only tested on Ubuntu, but the downloads page says “Linux”, so I expect that Vital was intended to work across distros, just like Helm does.
Yeah I’d like to support other distros (only officially supporting Ubuntu distros atm) and make things install cleaner but I didn’t have the time before release. I’m going to expand support to other distros but need to look into things like this.
I’ll see about statically linking a few things but I thought that was frowned upon.
libsecret is to remember login credentials which lets you auto download presets and make text to wavetable requests but I’ll see about making that optional.
Anyway yeah I’ll get to these kind of improvements and expand support down the line once things are stable in ‘officially supported’ systems.
There’s a trend towards delivering all files with the installation to avoid problems just like this. Ubuntu has Snap while other distros favor Appimage and Flatpak.
I think most users will be happy to get a working binary and won’t complain about statically linked libraries.
@Tytel I think it’s only frowned upon with open source software that becomes part of a distribution’s repository, because then the package is compiled by the maintainers and guaranteed to work with the system libraries.
With proprietary software, like Vital, the work of making the app compatible across all distributions befalls the developer exclusively. Helm is open source, which might be why you haven’t experienced this friction before.
I understand that there can be a few cons to open sourcing Vital. It’s no trivial task to be the maintainer of a code base which is subject to endless scrutiny, unsolicited patches and change requests. But at least issues like this could easily be solved by the community. Just a thought.
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
.) One can’t expect more than 24 hours in any one day 
.
