Sitala drum plugin

[Linuxmusician01]

@Raboof: thank you very much for clearing that up in layman's terms. So there are no dev kits and there's no person to blame here. Indeed, how Windows is so backwards compatible is a mystery to me too now. Anyway, as @kHz pointed out, I'll stop harassing y'all now 'bout my install problems.

But I'd like to stress that I appreciate VERY MUCH that some people/companies make (near)professional software for free via KXStudio, a standard distro or via ppa/website. Apps like Kdenlive, Qtractor, Libre Office and too many to mention are wonderful. Some companies would easily charge $200+ for each of them. The are like a Christmas present to me (to stay in the Holiday spirit )

[khz]

I think forum threads are not great for long-term knowledge storage, the wiki might be better for that.

If anyone wants to discuss these topics then by all means open threads there of course - and ideally summarize findings in a more long-term place .

Sounds good to me. To post to the wiki the forum / thread would be a help to discuss topics. I think there could be many different interests, variants, contingencies, aspects, possibilities, ... on these topics. You can't write these just like that.
Also the contributions in the Wiki should constantly grow, be updated/adjusted.

[khz]

@kHz pointed out, I'll stop harassing y'all now 'bout my install problems.

I myself have problems with the program (with ~my distribution Gentoo) and have asked about it here.
To make it clear: Everyone may and should be allowed to ask questions here! You, me, us, ... . User, developer, human, ... .
I think that how to develop programs for Linux / a distribution is a meta topic (libs, package manager, Ardour, KXStudio repositories, Flatpak, ..., what is ideal?).

Discussing this is helpful and doesn't mean that the user, developer, human can't ask!

[scottwheeler]

As a simple end-user it comes across like this: to simple little old me it looks as though development kit makers do not care about me as a user, they don't spend any time on assessing which versions of a library their stuff is really dependent. As a user I get the impression that the software in question does not rely on the new and improved things that new libraries offer. So they might as well be linked to older versions of the libs.

So why don't they? Software that depends on old libs work with the newest versions, but not the other way around...

I completely understand where you're coming from on this. But this last assumption is unfortunately wrong. It's true on Windows, and it's true to a lesser extent on macOS, but on Linux, it's absolutely not a reliable assumption that software that works with old libs will work on a newer system.

This is why most applications create packages for every Linux version they're targeting.

With Windows and macOS you can choose which version of the system you're targeting, and build packages for that version of the system, and are mostly guaranteed that they'll work for that system or any newer one. That just isn't true for Linux. Linux regularly has changes that make older packages not work.

So the choice becomes, instead, "Which distros and which versions are the most popular?" In our case, the thing we've had asked for the most was Ubuntu LTS, so that was the first distro we packaged for.

[scottwheeler]

Everything you said in your post is correct and a great explanation. Thanks! So I'll just respond to the one direct question here:

One commonly applied technique to distribute binaries that work across a number of Linuxes, already mentioned by Scott above, is by linking them statically. He is right to be careful about licensing pitfalls in this case, however: the same rules may not apply for static and dynamic linking.

in most cases using static linkage violates the licenses of the libraries that they're using (unless they're also shipping object files to allow the application to be re-linked, which I've never seen happen).

Scott: I wonder if that interpretation might not be too strict: indeed the LGPL allows static linking as long as you "also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application" (https://www.gnu.org/licenses/gpl-faq.ht ... cVsDynamic). If you make sure you (also) ship your plugin in object format, it seems to me like that would be sufficient - it is not necessary to also ship the object files of the libraries you depend on, as the user can obtain/build those themselves.

We were referring to the same thing with "object files" and "object format". It's something that I initially didn't consider, mainly because I've never seen any proprietary app take advantage of that portion of the LGPL. Things like, e.g. Reaper are statically linked, but as far as I can tell don't include their object files anywhere, so they're probably unknowingly violating the LGPL (which I admit is a subtlety easy to miss -- it's not intuitive that changing your compiler flags can result in a license violation). I'll play around with this and see how a statically linked Sitala fares. Back in the day (I was a very active Linux desktop developer in the early 2000s) you would still run into problems if you had two versions of the same library loaded into a binary because of global variable clashes and symbol collisions, but I think symbol visibility and thread safety may have improved enough at this point that it'd work. I'll give it a try.

[raboof]

the LGPL allows static linking as long as you "also provide your application in an object (not necessarily source) format

It's something that I initially didn't consider, mainly because I've never seen any proprietary app take advantage of that portion of the LGPL. Things like, e.g. Reaper are statically linked, but as far as I can tell don't include their object files anywhere, so they're probably unknowingly violating the LGPL (which I admit is a subtlety easy to miss -- it's not intuitive that changing your compiler flags can result in a license violation).

I agree this is easy to miss - and I suspect many upstream projects don't actually feel strongly about this aspect of the license either...

I applaud you for being aware of the issue and holding yourself to a higher standard.

I'll play around with this and see how a statically linked Sitala fares. Back in the day (I was a very active Linux desktop developer in the early 2000s) you would still run into problems if you had two versions of the same library loaded into a binary because of global variable clashes and symbol collisions

Hmm yes, good point.

but I think symbol visibility and thread safety may have improved enough at this point that it'd work. I'll give it a try.

Here's hoping!

[scottwheeler]

I agree this is easy to miss - and I suspect many upstream projects don't actually feel strongly about this aspect of the license either...

I applaud you for being aware of the issue and holding yourself to a higher standard.

Probably the difference is that I've written a lot of [L]GPL code, and as such am more familiar with the licenses. (Case in point: I wrote one of the libraries that Ardour bundles, and it's dual licensed MPL / LGPL specifically because the MPL does allow static linking without redistributing object files.) I suspect most folks porting music applications to Linux probably have less exposure to the OSS landscape.

[Linuxmusician01]

@kHz pointed out, I'll stop harassing y'all now 'bout my install problems.

I myself have problems with the program (with ~my distribution Gentoo) and have asked about it here.
To make it clear: Everyone may and should be allowed to ask questions here! You, me, us, ... . User, developer, human, ... .
I think that how to develop programs for Linux / a distribution is a meta topic (libs, package manager, Ardour, KXStudio repositories, Flatpak, ..., what is ideal?).

Discussing this is helpful and doesn't mean that the user, developer, human can't ask!

I fully agree. I was just afraid that I was going a bit to much off-topic which doesn't help me as a user nor the kind developer of this free piece of software. But you're absolutely right.

As a simple end-user it comes across like this: to simple little old me it looks as though development kit makers do not care about me as a user, they don't spend any time on assessing which versions of a library their stuff is really dependent. As a user I get the impression that the software in question does not rely on the new and improved things that new libraries offer. So they might as well be linked to older versions of the libs.

So why don't they? Software that depends on old libs work with the newest versions, but not the other way around...

I completely understand where you're coming from on this. But this last assumption is unfortunately wrong. It's true on Windows, and it's true to a lesser extent on macOS, but on Linux, it's absolutely not a reliable assumption that software that works with old libs will work on a newer system.

This is why most applications create packages for every Linux version they're targeting.

With Windows and macOS you can choose which version of the system you're targeting, and build packages for that version of the system, and are mostly guaranteed that they'll work for that system or any newer one. That just isn't true for Linux. Linux regularly has changes that make older packages not work.

So the choice becomes, instead, "Which distros and which versions are the most popular?" In our case, the thing we've had asked for the most was Ubuntu LTS, so that was the first distro we packaged for.

Thank you too for clearing that up in layman's terms.

[off topic] Like I said before: it's a pity that this might cause people to use Linux less than they might want to. Fortunately now-a-days almost all software (that I use) is in the standard repo of a distro or in KXStudio's repo. Do you think your plugin will make it into the standard repo of a distro? Or in the KXStudio repo? That may be a completely different discussion altogether, my apologies on beforehand for the off-topic...

[raboof]

on Linux, it's absolutely not a reliable assumption that software that works with old libs will work on a newer system. (...) With Windows and macOS you can choose which version of the system you're targeting, and build packages for that version of the system, and are mostly guaranteed that they'll work for that system or any newer one. That just isn't true for Linux. Linux regularly has changes that make older packages not work.

I'm curious why this appears to be less of a problem on Windows (I haven't done Windows development in ages), can you elaborate on that? You mention you "choose which version of the system you're targeting, and build packages for that version of the system", but that sounds like it is only true for the 'core system'. Above, part of what was problematic with libsitala as packaged for Ubuntu was a link to libcurl. Since libcurl does not come with Windows, all other things being equal you would expect Windows applications that use libcurl to have the same problem. But if I understand you correctly they don't. What is the difference? Do applications on Windows package their libraries with the application (a bit like the Ardour example), rather than sharing them? Or is there another distinction?

[khz]

That's why for now we just released a package for the most recent Ubuntu LTS, since that had up to now been the most requested distribution.

Ubuntu LTS is based on a Debian sid?
From a programming point of view this is not a problem? Debian sid is quite exciting sometimes (bugs, system changes (libs), update, ...), isn't it?
It's good to use, no question - I'm using Gentoo sid - but from a programming point of view I imagine it to be stressful.

[scottwheeler]

Fortunately now-a-days almost all software (that I use) is in the standard repo of a distro or in KXStudio's repo. Do you think your plugin will make it into the standard repo of a distro? Or in the KXStudio repo? That may be a completely different discussion altogether, my apologies on beforehand for the off-topic...

While some distros do include non-OSS software in their default repositories, my impression is that it's usually only stuff deemed sufficiently important -- things like (historically) Adobe's Flash Player, or proprietary graphics or wi-fi drivers. I'm skeptical Sitala would meet that standard.

[scottwheeler]

I'm curious why this appears to be less of a problem on Windows (I haven't done Windows development in ages), can you elaborate on that? You mention you "choose which version of the system you're targeting, and build packages for that version of the system", but that sounds like it is only true for the 'core system'. Above, part of what was problematic with libsitala as packaged for Ubuntu was a link to libcurl. Since libcurl does not come with Windows, all other things being equal you would expect Windows applications that use libcurl to have the same problem. But if I understand you correctly they don't. What is the difference? Do applications on Windows package their libraries with the application (a bit like the Ardour example), rather than sharing them? Or is there another distinction?

Unfortunately I can't give you a very satisfactory answer for Windows since I'm not an expert on the platform. I've worked on a number of products which I had to test on Windows, but I've always worked on them together with other people who were in charge of the Windows platform, so I've neither been in charge of packaging or deciding which libraries to use. (I do however know macOS fairly well in this regard.)

My impression is though that the lack of a well defined "core" set of libraries is part of the distinction. You'd typically statically link anything not included there. We don't use libcurl directly; it's brought in by a framework we use. On Windows and macOS that framework uses the system libraries to provide the function that's provided by libcurl on Linux.

In a way, the differences in the system evolved based on different selection pressure: Windows has a large stable SDK that has evolved to make shipping third party binaries as easy as possible. Linux reuses as much code as possible between applications which has advantages for memory usage and the ability to centrally patch bugs and security issues, but generally assumes that all packages for a system are being built centrally by the distribution.

Confounding things is that Linux isn't really one operating system, but a family of closely related operating systems. Slackware may decide to put config files in a different directory than Redhat or Debian or Gentoo. They may decide that even for a new release to stick to an old version of a library or compiler.

As a result, Linux projects usually have robust configuration systems in their source distribution to detect and adapt to these distinctions. But it also means that binary distribution for the entire family is difficult.

There was some attempt to address this with the Linux Standard Base some years ago, but my impression is that while it has improved the situation, it hasn't been as much as was once hoped.

[scottwheeler]

Ubuntu LTS is based on a Debian sid?
From a programming point of view this is not a problem? Debian sid is quite exciting sometimes (bugs, system changes (libs), update, ...), isn't it?
It's good to use, no question - I'm using Gentoo sid - but from a programming point of view I imagine it to be stressful.

All of Ubuntu is forked off of Sid, but there's a long process which turns those into Ubuntu releases. LTS is their "long term support" release, which they do every couple years, is intended to be particularly stable, and is supported by Canonical for 5 years. Again though, I'm not in the business of telling people which distribution they should be using. Ubuntu and its derivatives were simply the things we got the most requests for.

[windowsrefund]

Hello,

I'm going to try and get this thread back on track since I'm VERY interested in using Sitala from within Ardour 5.12. That's not happening at the moment due to the following:

Code: Select all

/opt/ardour/lib$ LD_LIBRARY_PATH=/opt/ardour/lib/ /opt/ardour/lib/ardour-vst-scanner -f /usr/lib/lxvst/libsitala.so 
[ERROR]: Could not open existing LXVST plugin: /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to_point
[WARNING]: Cannot get LinuxVST information from '/usr/lib/lxvst/libsitala.so': load failed.

My box wants you to know...

Code: Select all

$ uname -a
Linux windowsrefund 4.18.0-12-lowlatency #13-Ubuntu SMP PREEMPT Wed Nov 14 18:08:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/apt/sources.list | grep -v ^# | grep -v ^$
deb http://us.archive.ubuntu.com/ubuntu/ cosmic main restricted
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ cosmic universe
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-updates universe
deb http://us.archive.ubuntu.com/ubuntu/ cosmic multiverse
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-updates multiverse
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu cosmic-security main restricted
deb http://security.ubuntu.com/ubuntu cosmic-security universe
deb http://security.ubuntu.com/ubuntu cosmic-security multiverse

[GuntherT]

It appears you are using the binary from ardour.org on Ubuntu 18.10. The plugin is designed to work with the Ubuntu-packaged version of Ardour on Ubuntu 18.04.