Sitala drum plugin

All your LV2 and LADSPA goodness and more.

Moderators: MattKingUSA, khz

scottwheeler
Established Member
Posts: 20
Joined: Mon Dec 17, 2018 4:26 am
Location: Berlin
Contact:

Re: Sitala drum plugin

Postby scottwheeler » Mon Dec 17, 2018 10:20 pm

carlv wrote:We get this:
bash: /usr/lib/ardour5/ardour-vst-scanner: No such file or directory


Ah, so you didn't install Ardour from the Ubuntu packages, but from another source? (Direct download from their site?) If you can confirm that, I'll give it a try with whatever Ardour installation source you're working with.

User avatar
sysrqer
Established Member
Posts: 1658
Joined: Thu Nov 14, 2013 11:47 pm
Contact:

Re: Sitala drum plugin

Postby sysrqer » Mon Dec 17, 2018 10:43 pm

Try /opt/ardour/lib/ardour-vst-scanner

carlv
Established Member
Posts: 71
Joined: Tue Jul 12, 2016 6:10 pm

Re: Sitala drum plugin

Postby carlv » Mon Dec 17, 2018 11:20 pm

scottwheeler wrote:Ah, so you didn't install Ardour from the Ubuntu packages, but from another source? (Direct download from their site?) If you can confirm that, I'll give it a try with whatever Ardour installation source you're working with.


KXStudio repos., so as sysrqer points out the ardour-vst-scanner resides here for me: /opt/ardour/lib/ardour-vst-scanner.
I re-wrote your code, hopefully correctly to reflect (LD_LIBRARY_PATH=/opt/ardour/lib /opt/ardour/lib/ardour-vst-scanner -f /usr/lib/lxvst/libsitala.so ) ran and got back...

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/libwebkit2gtk-4.0.so.37: undefined symbol: g_output_stream_write_all_async
[WARNING]: Cannot get LinuxVST information from '/usr/lib/lxvst/libsitala.so': load failed.

User avatar
lilith
Established Member
Posts: 730
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Contact:

Re: Sitala drum plugin

Postby lilith » Mon Dec 17, 2018 11:46 pm

scottwheeler wrote:Hi - this is Scott, one of the guys from Decomposer that make Sitala (and I'm the one that did the Linux package).

Sitala's always worked on Linux, but packaging / testing for Linux is complex relative to other platforms simply because there are so many different Linuxes one can target. 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.

It's possible we'll include other Linux distributions at some point down the line. Mostly it depends on how much uptake we see on Linux in general. Right now packaging for just one Linux distribution is approximately as complicated as packaging for macOS or Windows, but as of today, our Linux package has a whopping ... 23 users (compared to hundreds on the other two platforms). Shipping for a large set of distros is unlikely unless those ratios change significantly.


Thanks for supporting linux anyway and thanks for fast reply to my email :).
https://soundcloud.com/lilith_93
_____________________________
Debian 9 (XFCE) & KXStudio repos

scottwheeler
Established Member
Posts: 20
Joined: Mon Dec 17, 2018 4:26 am
Location: Berlin
Contact:

Re: Sitala drum plugin

Postby scottwheeler » Tue Dec 18, 2018 4:09 am

carlv wrote:KXStudio repos., so as sysrqer points out the ardour-vst-scanner resides here for me: /opt/ardour/lib/ardour-vst-scanner.


Hmm, as far as I can tell, Ardour isn't actually contained in the KXStudio repos (which I didn't realize until I got them set up and reinstalled ardour just to see it was being pulled from the same standard Ubuntu location). If it was there, it would show up in this file, I believe:

http://ppa.launchpad.net/kxstudio-debia ... ackages.gz

carlv
Established Member
Posts: 71
Joined: Tue Jul 12, 2016 6:10 pm

Re: Sitala drum plugin

Postby carlv » Tue Dec 18, 2018 4:27 pm

scottwheeler wrote:
carlv wrote:KXStudio repos., so as sysrqer points out the ardour-vst-scanner resides here for me: /opt/ardour/lib/ardour-vst-scanner.


Hmm, as far as I can tell, Ardour isn't actually contained in the KXStudio repos (which I didn't realize until I got them set up and reinstalled ardour just to see it was being pulled from the same standard Ubuntu location). If it was there, it would show up in this file, I believe:

http://ppa.launchpad.net/kxstudio-debia ... ackages.gz


I picked it up from here http://kxstudio.linuxaudio.org/Reposito ... plications back around 2016 or there about. It works, so haven't thought about it much since. Can't help in that regard much beyond that, unfortunately.

Thanks and happy sleuthing.

scottwheeler
Established Member
Posts: 20
Joined: Mon Dec 17, 2018 4:26 am
Location: Berlin
Contact:

Re: Sitala drum plugin

Postby scottwheeler » Tue Dec 18, 2018 6:47 pm

carlv wrote:I picked it up from here http://kxstudio.linuxaudio.org/Reposito ... plications back around 2016 or there about. It works, so haven't thought about it much since. Can't help in that regard much beyond that, unfortunately.


So, as I said, LXStudio doesn't actually ship Ardour anymore. I decided, however, to try the direct download from the Ardour page, and I did get the same error as you're getting. So I'll assume that the LXStudio packagers were just packaging the binary from the Ardour download page.

The problem is this: that package contains old copies of a lot of system libraries and overrides the default system libraries with those old versions, and forces those overrides on any plugins that it loads. Sitala (and anything built with a current version of JUCE, an audio app framework -- I found other instances here in the forum of people hitting similar issues with other plugins) expects those libraries to be the current system libraries. This is pretty bad packaging practice from Ardour.

Fortunately, the version available from their website isn't any more current than the version available from the default Ubuntu repositories (that you'd get with standard `apt install ardour`), and the Ubuntu packages are created correctly, so there's really no good reason to continue to use the things from Ardour's site.

scottwheeler
Established Member
Posts: 20
Joined: Mon Dec 17, 2018 4:26 am
Location: Berlin
Contact:

Re: Sitala drum plugin

Postby scottwheeler » Tue Dec 18, 2018 7:11 pm

I'm not entirely sure that I would recommend this (since I don't know what assumptions Ardour makes about the old libraries), but just doing this makes things work for me:

Code: Select all

cd /opt/Ardour-5.12.0/lib
mkdir old
mv libgio-2.0.so.0 libglib-2.0.so.0 libgobject-2.0.so.0 libharfbuzz.so.0 old/


After that Ardour runs fine, and loads Sitala without problems.

Basically that removes Ardour's overrides of the relevant system libraries (but still leaves many other ones in place -- again, their packaging process is very questionable), and gets things working for Sitala.

GuntherT
Established Member
Posts: 79
Joined: Sun Jun 07, 2015 2:15 am

Re: Sitala drum plugin

Postby GuntherT » Wed Dec 19, 2018 4:55 pm

I don't think Ardour's packaging is bad or questionable, just different in its purpose. The binaries from ardour.org aim to be distro-agnostic with the expectation that plugins be distro-agnostic as well. You have chosen to package your plugin to be distro-specific, which means it will be compatible with the Ubuntu-packaged version of Ardour but perhaps not the official binary. Each approach has its justifications. However, I think you would reach more users if you packaged it for Debian Stable instead of Ubuntu 18.04. AFAIK, a *.deb file that installs properly on Debian Stable will also install on Ubuntu 18.04 along with numerous other distros. Someone should correct me if I am wrong about that.

Thank you for the plugin and your efforts to make it available for Linux users.

scottwheeler
Established Member
Posts: 20
Joined: Mon Dec 17, 2018 4:26 am
Location: Berlin
Contact:

Re: Sitala drum plugin

Postby scottwheeler » Thu Dec 20, 2018 4:09 am

GuntherT wrote:I don't think Ardour's packaging is bad or questionable, just different in its purpose. The binaries from ardour.org aim to be distro-agnostic with the expectation that plugins be distro-agnostic as well.

It would be a little ugly, but understandable if they were shipping an application which does not load third party plugins. Then the worst that would happen is that that application wouldn't get security updates and bug fixes that were fixed in later versions of the libs it uses. But doing that for something which loads plugins is genuinely crappy.

Their binary isn't system agnostic because it targets older, more compatible versions of things. It's system agnostic because they ship (old, but only because their binary package is a couple years old) versions of every single library that they use. To create plugins that would be reliably loaded with those versions, they'd need to ship an SDK that you could build your plugins against, but then they wouldn't be guaranteed to work with other applications on the system. Effectively Ardour is a mini-distro.

I'm calling it "crappy" because I don't think it's reasonable to force third parties to package and test things against their mini-distro rather than the system provided and updated libraries.
However, I think you would reach more users if you packaged it for Debian Stable instead of Ubuntu 18.04. AFAIK, a *.deb file that installs properly on Debian Stable will also install on Ubuntu 18.04 along with numerous other distros. Someone should correct me if I am wrong about that.

You are wrong about that:

https://unix.stackexchange.com/question ... ith-debian

It's possible that coincidentally a Debian Stable package of Sitala would work with Ubuntu 18.04, but there are no guarantees of such. Nevertheless, since in theory we have a deb packaging script that I think should work on Debian too, I'm curious enough that I'm doing a VirtualBox install of Debian Stable now to try it out.

User avatar
Linuxmusician01
Established Member
Posts: 276
Joined: Mon Feb 23, 2015 2:38 pm
Location: Holland

Re: Sitala drum plugin

Postby Linuxmusician01 » Thu Dec 20, 2018 10:10 am

With all do respect. I'm not a developer/programmer: I know very little about it and have no experience with it. First of all I would like to thank @ScottWheeler very, very much for taking Linux seriously and porting his plugin to Linux. You're the greatest man. :)

In the old days (say, around 2005) I still used Windows. A friend of mine is a software developer and in his free time he made a program that manages virtual football teams for a game he played with friends. He'd sometimes ask me to install this program to test it and to show the progress he made. This program would on occasion not install on my Windows version because it would need libraries specific to the development stuff that he used. I constantly had to download and install new .net stuff or something like that. My developer friend hated that because the guys he made the software for weren't keen on installing all sorts of extra stuff for the football app. Some didn't even know how to do that.

Now what's the point of the story above? Not dependency hell. I think we're past that in Linux. Again, I don't know nothing 'bout developing software so I could be offending people here which is not my intention. I just look at things from a user perspective. The point is that some software development kits (that's what you call it, right?) support specific configurations of a system for which the software is intended. That's where the problem lies in my opinion. Systems like Windows and MacOS are - again: I ain't no professional - sort of "frozen in time" and very "predictable". They should be, and can be, very easy to make software for. Just like Android and iOS: almost all apps are compatible w/ each phone and backwards compatible w/ old ones.

But just like the .net application that my friend built back in the day, a lot of Linux software that one can download from the internet (rather than from the standard repo from your distro) is extremely hungry for the latest and greatest libraries. And as a user you get the sneakin' suspicion that for a simple little app like a football manager or a drum kit emulator/VST that's not necessary.

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 know that there probably is a good reason that dev kits (if that is what one calls it) are dependent of the latest stuff and even if you support old libs then the question is: how far back in time should you go with support? Ten years? One year?

Fact of the matter is that the latest version of MS Word probably still works on Windows XP. But a drum plugin won't work on a Linux distro that is a few years old. Or it won't work because of the reasons explained here concerning the packaging of Ardour.

I consider this to be one of the reasons people wont switch to Linux. I personally don't mind that much anymore because I don't care for the latest and greatest versions of applications: a version that is a few years old is good enough for me. I probably won't notice the "new" additions anyway.

It appears to me (like stated more then once: from the targeted users perspective, I ain't no pro) that in this case there's a problem w/ hard linking to old libs by one app (Ardour) and dependency on a specific distro and specific libs of a second app (Sitala). Reminds me of the .net problem my friend had...

Why are dev kits so hungry on new libs? If they weren't we wouldn't have the problems w/ Sitala (it would have worked w/ the libs that Ardour wants to use etc.).

Sorry, had to get that off my chest. :|

User avatar
davephillips
Established Member
Posts: 471
Joined: Sat Aug 15, 2015 1:05 pm

Re: Sitala drum plugin

Postby davephillips » Thu Dec 20, 2018 12:27 pm

Greetings,

I think that technical and non-technical users have missed the actual fact of what's happening. Like other distros Ubuntu uses libraries with versioned symbols, so if you try to run a binary-built-on-Ubuntu that requires versioned symbols later than your system supports, you are out of luck unless 1) you update your entire system or 2) you can update only the required libraries or 3) you know how to use LD_LIBRARY_PATH and can point the binary to a location with the required libs or 4) you can convince the developer to stop using versioned libraries, which would probably mean not using Ubuntu as a development environment, which given its popularity is not likely to happen.

Or 5) you can build it yourself from the source code. The resulting binary will then require whatever system versions it was built with, but at least it'll run on your local system. Alas, AFAICT the source for Sitala is not freely available.

Here's why Sitala won't run on my ancient Fedora 23 system. This is what it wants :

Code: Select all

$ ldd sitala
./sitala: /lib64/libcurl-gnutls.so.4: no version information available (required by ./sitala)
./sitala: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by ./sitala)
...


These are the GLIBC versions supported by my /usr/lib64/libm.so.6 :

Code: Select all

$ nm libm.so.6 | grep GLIBC
...
0000000000000000 A GLIBC_2.15
0000000000000000 A GLIBC_2.18
0000000000000000 A GLIBC_2.2.5
0000000000000000 A GLIBC_2.4
...


Some background about versioning:

http://harmful.cat-v.org/software/dynam ... ed-symbols

Best regards,

dp

User avatar
raboof
Established Member
Posts: 1568
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: Sitala drum plugin

Postby raboof » Thu Dec 20, 2018 1:20 pm

Linuxmusician01 wrote:With all do respect. I'm not a developer/programmer: I know very little about it and have no experience with it. First of all I would like to thank @ScottWheeler very, very much for taking Linux seriously and porting his plugin to Linux. You're the greatest man. :)


Seconded ;).

Linuxmusician01 wrote:I don't know nothing 'bout developing software so I could be offending people here which is not my intention.


Thanks for spelling this out ;).

Linuxmusician01 wrote:The point is that some software development kits (that's what you call it, right?) support specific configurations of a system for which the software is intended


On linux, there isn't really a 'software development kit' in the way you describe - you just install the 'development files' of the libraries you want to program against, which typically are packaged in your distro's package manager.

Linuxmusician01 wrote: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


It is certainly not about 'not caring about the user': when publishing open source software, while most of the time the maintainer is also a user of the software, doing it 'just for yourself' is not really worth it. So putting in all the work needed to publish the software is certainly a testament that open source developers certainly care about their users. Commercial developers of course also tend to care about their customers.

Linuxmusician01 wrote: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?


As I noted above, as a developer the easiest thing to do is just to build against whatever version is packaged with the distribution I am using during development. Building against specific versions is possible but cumbersome. Testing that the code also works with older versions of those libraries is possible, but "going an extra mile".

Linuxmusician01 wrote:Software that depends on old libs work with the newest versions, but not the other way around...


Unfortunately, this is not true: this is called 'keeping backwards compatibility', so software that depends on old libraries will also work with newer versions. To split hairs, this has 2 parts: 'binary backwards compatibility' (making sure projects written for an older version can link to a newer version) and 'source backwards compatibility' (making sure projects written for an older version can compile against a newer version).

The thing is, this is very hard - both in the sense that it takes a lot of effort, and that it is easy to get wrong.

This is part of the reason Ardour, when taken from the homepage, ships with its own version of the libraries instead of relying on the versions installed on your system. This has the advantage Ardour is not affected by compatibility problems when running on a system with unpredictable versions of those libraries. It has the disadvantage that any plugins loaded into Ardour also 'inherit' those versions of the libraries, making the plugins fail even when they were built for the libraries that ship with your distribution...

Linuxmusician01 wrote:Fact of the matter is that the latest version of MS Word probably still works on Windows XP.


Actually you'll need Windows 7 (https://products.office.com/en-US/buy/office), but your point stands, that's also 9 years ago.

Linuxmusician01 wrote:But a drum plugin won't work on a Linux distro that is a few years old.


One thing to remember here is a plugin is a little more complicated than an application: because plugins loaded into Ardour 'inherit' the versions of the libraries shipping with Ardour, things are more complicated.

Linuxmusician01 wrote:I consider this to be one of the reasons people wont switch to Linux. I personally don't mind that much anymore because I don't care for the latest and greatest versions of applications: a version that is a few years old is good enough for me. I probably won't notice the "new" additions anyway.


For popular open source software, of course it is likely that this has been solved by the distribution: part of packaging is making sure a version of the software is built which works together with the versions of the libraries available in the distribution.

For obscure open source software, it might run, if any libraries it uses are either included (like with Ardour) or compatible with the versions on your system. If it doesn't, then you can try and build the project from source - perhaps making some adjustments to make it build against more modern versions of libraries. Building from source can be tricky, sometimes out of reach for 'regular users' - but it great that it is possible at all.

For proprietary software distributed as binaries, they are in a bit of a pickle: since the distributions won't take care of building their software, they must themselves make sure to build their software against libraries commonly found in distributions. That can be quite a challenge.

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.

scottwheeler wrote: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.

Linuxmusician01 wrote:It appears to me (like stated more then once: from the targeted users perspective, I ain't no pro) that in this case there's a problem w/ hard linking to old libs by one app (Ardour) and dependency on a specific distro and specific libs of a second app (Sitala).


More generally, I think the problem is that different applications are sharing the same libraries. If one application could use one set of versions of libraries and another application could use another, that would already help a lot. There have been some packaging approaches (such as the previously discussed Flatpak) that promote this idea, but I don't think any of those ever really became popular.

For plug-ins the problem is even more tricky. Treating plugins more like individual applications would help here, but it seems that isn't how VST works.

Linuxmusician01 wrote:Reminds me of the .net problem my friend had...


It would be interesting to know whether and, if so, how this is solved on Windows. They certainly used to suffer from that same problem ('DLL Hell'), but I haven't kept up. I suspect they either package libraries with their applications (Ardour-style) or link statically. Someone with more Windows experience should confirm, though.

Linuxmusician01 wrote:Why are dev kits so hungry on new libs? If they weren't we wouldn't have the problems w/ Sitala (it would have worked w/ the libs that Ardour wants to use etc.).


I hope the (slightly rambling) explanations above help understand some of the issues. As said, static linking of Sitala might already help a lot (though probably not with libc versions), and might not be as problematic license-wise as was suggested earlier.

User avatar
khz
Established Member
Posts: 965
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Sitala drum plugin

Postby khz » Thu Dec 20, 2018 2:49 pm

@scottwheeler @raboof @all
Would it be helpful to create extra threads in the Developer's Section?
To exchange among developers about such topics as for example:
- What are the possibilities to develop software under linux (for example: dependency problems (libs) / ...)
- Advantages and disadvantages
- Software license GNU GPL
- Distribution of software / Updates / ...
- ...

That would be a help for all (future) developers to grasp and discuss such basic topics and thereby gain clarity(s) or discuss optimal way(s)?
FZ - Does humor belongs in Music?
GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
    I don't care about the freedom of speech because I have nothing to say.

User avatar
raboof
Established Member
Posts: 1568
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: Sitala drum plugin

Postby raboof » Thu Dec 20, 2018 3:24 pm

khz wrote:Would it be helpful to create extra threads in the Developer's Section?

That would be a help for all (future) developers to grasp and discuss such basic topics and thereby gain clarity(s) or discuss optimal way(s)?


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


Return to “Plugins, Effects and Instruments”

Who is online

Users browsing this forum: No registered users and 1 guest