Sitala no more Linux support

[miuzik]

Sitala 2.0, Released June 15, 2023.

From its FAQ section:

Q: Why isn’t Linux supported in Sitala 2.0?

This is a hard one for us, since both Sitala developers come from a background in Linux multimedia.

The truth is the Linux version has always been buggier than the versions for macOS, Windows and iOS. We felt like we could kind of get away with that when we weren’t charging for it, but when users pay for software, there’s a reasonable expectation of it, well, working.

Most of the bugs come from the framework we use (JUCE) and in the past we’ve spent a lot of time hunting down Linux bugs in JUCE, and sent them upstream to a big resounding nothing.

On top of that, packaging on Linux is a bugger. We’ve tried to just target the most recent Ubuntu LTS, because we just can’t afford the time to test and debug on a dozen Linuxes (which is about 0.9% of our user base), but of course that doesn’t stop folks from trying and using Sitala on other distros.

As a result of these inconvenient truths, Linux is about 1% of our user base, but about a third of our support mail. Up to now we’ve been resigned in just throwing our hands up in the air when people hit issues that are real, but that we can’t economically test or debug, but that feels smarmy when we’re charging people cash for things. So, at least for this release, we’re going to sideline our Linux support.

Our previous release is still available for download.

It's a pity, it isn't free software but almost had Linux version. But... Is the current situation for software development in Linux so bad?

[Kott]

Is the current situation for software development in Linux so bad?

I don't have "badness" scale, but these two points looks fair:

Most of the bugs come from the framework we use (JUCE) and in the past we’ve spent a lot of time hunting down Linux bugs in JUCE, and sent them upstream to a big resounding nothing.

On top of that, packaging on Linux is a bugger. We’ve tried to just target the most recent Ubuntu LTS, because we just can’t afford the time to test and debug on a dozen Linuxes (which is about 0.9% of our user base), but of course that doesn’t stop folks from trying and using Sitala on other distros.

[porzione]

As far as I know - only one person in u-he works on everything Linux related, same with TAL. And we have imho better Apisonic Speedrum, and again it's just one person.
Maybe the situation in far from perfect but looks like Sitala is just side project for the dev.

[Linuxmusician01]

Q: Why isn’t Linux supported in Sitala 2.0?
[...] On top of that, packaging on Linux is a bugger.

They invented Linux VST and Clap for that. You should not distribute plugins as a package for Linux or a self installing .EXE in Windows. One simply drops the .dll or .so file in the proper directory.

One distributes software (not plgins) as a .exe or package.

[miuzik]

Q: Why isn’t Linux supported in Sitala 2.0?
[...] On top of that, packaging on Linux is a bugger.

They invented Linux VST and Clap for that. You should not distribute plugins as a package for Linux or a self installing .EXE in Windows. One simply drops the .dll or .so file in the proper directory.

One distributes software (not plgins) as a .exe or package.

I agree

[j_e_f_f_g]

One simply drops the .dll or .so file in the proper directory.

It may not be that simple. First of all, maybe the plugin is comprised of several files. For example, a No Budget plugin consists of a small stub that contains logic specific (ie unique) to that plugin. (For an LV2 plugin, examples of that unique data is the plugin's URID and run function). By contrast, logic that is shared by all plugins is separated into its own dynamic link library. In this way, only one copy of that shared code gets loaded into memory regardless of how many No Budget plugins you use. Now, in order for a host to detect an LV2 plugin, that plugin's manifest, ttl, and plugin specific code need to be in its own directory, But you can't place the shared library in that directory, because all the other No Budget plugins need to find it too. So the enduser would need to know where to place shared libs on his OS. (Linux standard file hierachy indicates /usr/share/libs. Of course, Windows has a different place for shared libs).

An additional linux concern is with file permissions. An enduser can't just drop his plugin data files into /usr/local/lib/lv2 (so all user accounts have access to it)... unless he has adminstrator rights, or is logged in as root. And even if he does that, he may still need to set a file's permission bits, for example, setting the executable bit on the plugin's data, and gui, libs.

In conclusion, the installation of software may involve more than just copying/pasting one file, as is. It may involve more, and in that case, it's a bad idea to leave it to the enduser to get it all right.

[Linuxmusician01]

One simply drops the .dll or .so file in the proper directory.

It may not be that simple. First of all, maybe the plugin is comprised of several files. For example, a No Budget plugin consists of a small stub that contains logic specific (ie unique) to that plugin. (For an LV2 plugin, examples of that unique data is the plugin's URID and run function). By contrast, logic that is shared by all plugins is separated into its own dynamic link library. In this way, only one copy of that shared code gets loaded into memory regardless of how many No Budget plugins you use. Now, in order for a host to detect an LV2 plugin, that plugin's manifest, ttl, and plugin specific code need to be in its own directory, But you can't place the shared library in that directory, because all the other No Budget plugins need to find it too. So the enduser would need to know where to place shared libs on his OS. (Linux standard file hierachy indicates /usr/share/libs. Of course, Windows has a different place for shared libs).

An additional linux concern is with file permissions. An enduser can't just drop his plugin data files into /usr/local/lib/lv2 (so all user accounts have access to it)... unless he has adminstrator rights, or is logged in as root. And even if he does that, he may still need to set a file's permission bits, for example, setting the executable bit on the plugin's data, and gui, libs.

In conclusion, the installation of software may involve more than just copying/pasting one file, as is. It may involve more, and in that case, it's a bad idea to leave it to the enduser to get it all right.

I agree. But if it's so darn hard to create a .deb or .rpm that'll work for everybody (as the Sitala devs whine about like a little 4-year old) then a simple readme would do (and they can stop whining). Remember that Linux is not for the faint of heart: you have to do a 'sudo' anyway to install a .deb. And if you are a developer that thinks that Linux is a bit too complex to support then you might want to Keep It Simple for the Stupid (the well-known k.i.s.s. principle): make sure your plugin is a simple .dll or .vst. If need be with some additional stuff in a dir that's set in a .myconfig configuration file in the home dir. Done simple, no libraries. But it requires developers that want to really program and who do not wat to use "development suites" that generate fancy schmancy shite that they think looks cool, which Sitala by the way most definitely does not. Anybody paying $20 for that must be out of his bloody mind if you compare that to Hydrogen.

We're not talking rocket science here, an Office Suite or molecular modeling software. It's a simple cheap-ass drum plugin. I think we can all safely happily without it.

So. That my rant.

[j_e_f_f_g]

if it's so darn hard to create a .deb or .rpm that'll work for everybody

Well that's the thing. A deb or rpm can never work "for everyone". In addition to linux devs constantly reinventing the wheel with the result that you have no standards, compatibility, or reliability with software (ie, PulseAudio, Pipewire, etc), distro maintainers have done the same thing with package managers/formats. At this point, the goal of creating one linux package that installs on all distros is hopelessly and permanently unachievable.

I tried to distribute my software via a rpm and deb, and in practice it failed, in large part due to "dependency hell".

Fortunately, I've been lucky to have learned two important things as a developer.

1) Learn from other people's mistakes. Before you start something new, take a look around for any existing, similiar work that others have done. Study why and how those things have failed, as well as succeeded. Learn what not to do before you try doing it. OSS devs are constantly neglecting to do this, and in large measure, it explains why there are so many OSS failures/disasters, and in the lucky event the OSS dev gets something right, he usually could have gotten a lot more right if only he had DONE SOME FREAKING RESEARCH FIRST.

2) Steal the good ideas other people have come up with. Don't ignore other ideas just because they aren't your own. The vast majority of "my" good ideas I "borrowed" from someone else. Lots of them. I love taking other folks' ideas, and going from there. It has made me much more successful in my projects.

I was reading about "Arch recipes" on AUR, and I decided to steal that idea. Instead of creating a package of my No Budget Plugins, I decided to create my own version of an arch recipe for them. I would create my installer as a bash script. This gets around the package format issues. Fortunately, OSS devs haven't screwed around with too many "shells" and shell languages. So, a bash script is just about the only thing that you can reasonably expect to run correctly on just about every distro. Also, my installer would not just install binaries on a system. Like an arch recipe, it would try to automatically compile my plugins on a given system (ie, the source code is included with my installer script). This would solve the dependency issues, since the software would be created specifically to use whatever versions were already on that system.

Hopefully, this will work well. If it doesn't, then I'm giving up on attempting to install software, I will resort to supplying the enduser with generic instructions on how he should proceed to manually install the software, and leave it entirely up to him to do it (and get it right). Certainly such an approach is very user-unfriendly, and if more devs do it, it will likely discourage users from migrating to linux (from operating systems where it's common and easy to install software). So be it, I'm not going to waste my time trying to make things easier for linux endusers, while so many other linux folks are doing things that just make my goal harder.

[Linuxmusician01]

I would create my installer as a bash script. This gets around the package format issues.

Well said. Lots of software from "big" companies come with an installer script. That way experienced Linuxers can also see what the hell happens and, God forbid, streamline the install of the whole shebang (libs and all).

[...] I will resort to supplying the enduser with generic instructions on how he should proceed to manually install the software

No problem for 99% of us. Unless we're talking Office Suite or something complicated like that of course, in which case I'd appreciate a package. And that's why I always encourage (beginning) Linuxers to install Debian, Ubuntu or another well-supported distro. Most LibreOffice updates are available for Ubuntu, the rest is only so/so supported.

But a plugin in a friggin' package or self installing .exe? That can only mean one thing: bloat and a dev who doesn't know his operating system. Usually stuff like that is made in an IDE instead of a text editor and C. Which should be avoided like the plague. Not C that is, but the bloatware.

[GMaq]

@Linuxmusician01

But if it's so darn hard to create a .deb or .rpm that'll work for everybody (as the Sitala devs whine about like a little 4-year old)

It is EXACTLY entitled comments and attitudes like this that make developers go "f**k Linux, not worth the effort!... If the absolute nightmare that Linux packaging is (and is only making worse) isn't certainly something to whine about I don't know what is..

Wait until flatpak really takes hold and Plugin developers find out the flatpak Plugins on Linux have be be placed in a whole separate location for the flatpaks to access them, even Deb, RPM and those providing Plugin binaries could agree on standardized install locations in the Linux filesystem, now flatpak is adding a whole other problem for developers to accomodate.

[oddy.o.lynx]

I was also disappointed that Sitala dropped Linux support

An excellent maybe even better alternative is Speedstrum

https://www.apisoniclabs.com/

They also have a free Lite version

[Kott]

It's unclear what packaging means here. But I suppose it's a dependencies. Ubuntu LTS is fine for that, except you forget to disable CURL for your JUCE based plugin, which is a case for sitala, I guess.

[miuzik]

The U-he model is very agnostic and easy. A script installs all in local folders, no sudo and all works very well.

[j_e_f_f_g]

U-he model is... a script

A bash script? If so, I presume you first have to go into its Properties to set the executable permission bit (or issue chmod) on that script? And then you need to run it from a terminal window? And I presume it has no graphical UI (ie, all user interaction is via typing text in the terminal window)?

install all in local folders

You mean in your home folder's hidden .lv2 directory?

One problem there is only that one account has access to those plugins. If you want them available to another account, you either have to install a duplicate copy to that account's home folder, or you need to install to /usr/local/lib/lv2.

My script asks the user if he wants the plugins installed for "only the current user", or for "all users". Then based upon his response, it will install to either the local folder, or the shared folder.

I initially tried presenting a graphical interface to interact with the enduser using the "dialog" utility. But that proved to be troublesome. So my installer is text-based, needs to be set executable, and needs to be run from a terminal window. No way I know of to simplify it any further without troubles.

It works. But compared to the ease and efficiency of installing software on Windows, MacOS, iOS, android, etc, this approach is about as graceful as Rosanne Barr falling down a flight of stairs.

[Linuxmusician01]

I was also disappointed that Sitala dropped Linux support

An excellent maybe even better alternative is Speedstrum

https://www.apisoniclabs.com/

They also have a free Lite version

And they distribute this plugin as a single Zip file for Win, Linux & Mac. The Win version has only 2 files: a .dll (= vst2) and a .vst3 file without even a ReadMe. That's how you do it! I'll bet you a million dollars that every Win Musician knows in what dir to drop those. Done. KISS: Keep It Short & Simple.