AppImages Problems with Effects

These error messages always appear in the AppImages:

ladspa.1204 = Triple band parametric (Equalizer)
ladspa.1882 = SC4, Compressor
ladspa.1890 = Glame Highpass Filter
ladspa.1891= Glama Lowpass Filter
ladspa.1913 = Fast Lookahead limiter

These are very important filters for audio editing. They are of course there in the normally installed version of Kdenlive because I installed Steve Harris’ LADSPA SWH-Plugins.
It would be very nice if these filters were built into Kdenlive as standard.
If this does not happen, how can I use these effects in an AppImage?

Please report this as a bug in Thanks!

I ran into something like this trying to use external Frei0r plugins with the appimage (cf.

It should be possible to let the appimage search standard system locations for these, or to respect user environment variables which specify them - but right now the apprun wrapper seems to unconditionally set them to look only inside the appimage filsystem.

1 Like

Hallo Bernd,
I very much doubt that it is a bug. AppImages probably can’t access installed plugins that well. I had to install a few extra things for the installed version of Kdenlive.
But my question is whether Kdenlive could not install these very important filters by default. Or maybe it should.
At least the equalizer (tap-plugins) and the compressor SC4 (from Steve Harris’).
Tell me if this is really a bug and I will report it.

All of those filters are present in the data/filters directory of the Kdenlive source and should therefore be part of the appimage which has everything in one nice bundle not relying on the user’s installation of filters. Hence I think it’s a bug …

Hello Bernd,
in order to use the above mentioned filers in the normal, installed version of Kdenlive, I have to install swh-plugins from Steve Harris’ LADSPA. Is that not the case for you?

I have to correct myself: The data/effects directory has LADSPA filters but not the SWH Plugins. I do have them all in the ppa installed version of 23.08.5 version. Unfortunately, ppa is no longer supported.

Turn your original post into a [Feature Request] in the bug tracker.

The tap plugins should already be included in the appimage (I packaged those for replicating the appimage support in the last round of testing gyroflow) - but maybe not the SWH ones.

The appimage wrapper hardcodes:

where $this_dir is the appimage filesystem root. If it let the user append things to that, or included dirs outside the appimage, then you should be able to use externally installed plugins with it. Likewise for FREI0R_PATH.

1 Like

Hello Ron,
Thank you very much for your commitment.

Yes, there are TAP Plugins in the AppImage:

But please note that I am an eternal Linux beginner, so I understand very little of what you are writing.
To formulate my request a little more clearly: At the moment I have no problem because I can do everything I need to with Kdenlive. This applies to the versions installed in Manjaro Linux.
But what if it stops working one day? What if I have to switch to an AppImage if necessary, because the current update of Kdenlive can do too many new things and at the same time contains significant bugs?
Then I use an AppImage, but then unfortunately the SWH won’t work. What do you do then?
Or even better: Can you ensure that these are built into Kdenlive?
Best regards

PS. Are you one of the developers?

All those what-if’s are kind of the nature of the Free software beast. We have the source code and a licence to use it, so if someone stops doing something We want one day then We have the ability to step in and start doing it again … If there are bugs that particularly annoy us, We have the ability to debug and patch them. Or to revert to previous versions where they are less annoying.

But that’s philosophy, that doesn’t help your immediate problem :slight_smile:

So with that said … I’m kind of old school, my first preference is for a tested linux system, where like Debian or Arch (which Manjaro is based on) all the dependencies kdenlive needs are shipped as system packages, as is kdenlive itself.

But kdenlive, and a few of its essential dependencies, really is moving Too Fast for most people to be happy with using a Stable version for an extended period before the next Stable release can be thoroughly tested and rolled out. Every new release brings Significant usability improvements - so until it gets to the point where it’s Nearly Perfect, and new releases are just adding some extra gloss to it, it makes sense for users to be able to use each new release immediately from the day it comes out, and for them to be using a known and well controlled build so that its developers can find and reproduce and squash bugs quickly, without wasting hours chasing some report only to find that it’s a problem that the Ubuntu maintainer introduced in some marginal dependency with a knee-jerk patch to hide a problem in some unrelated space.

So I mostly use the kdenlive appimages too. And I have a big collection of all the ones I’ve used for each project, so that if I ever need to go back and make a small edit, or re-render that project, I can (hopefully) use the version it was last edited with, instead of needing to roll the dice on what updating to the current version might change to make what I want to do a more major project of its own.

But I also have a private repository packaging all of the ‘active’ kdenlive deps directly from git, so that I can build Bleeding Edge versions on the rare occasions when I need to experiment with something the appimage doesn’t support, and which I can patch if needed.

I’m not one of the kdenlive developers, right now I’ve still been too busy just using it to contribute to the code, and they’ve mostly done an excellent job of scratching my itches before I’ve needed to write code myself to do so :smiley: But if you’re running any flavour of linux, there’s code I’ve written or contributed to scattered all through your system.

That should give you enough context to have a sense of where I see things from,
so back to your current problem:

Manjaro, like most distros, uses the FHS to determine where packages put their files, and where other packages should look for them:

So in the case of LADSPA plugins, packages which provide them put them in /usr/lib/ladspa and packages which use them look for them there, and that is all the coordination those packages need between each other provided they all follow the LADSPA plugin API.

But an Appimage provides an Almost self contained FHS filesystem, mounted in /tmp on the system, which contains all of the dependencies the appimage provides itself in place of the system ones. It still uses some of the system libraries, but it provides or overrides some subset of them.

In the case of plugins, it is possible to allow the appimage to look for them in system filesystem locations outside of what the appimage provides, but the current appimage does not do that, it only looks at what was shipped with the appimage.

Allowing the appimage to look outside what it provides probably needs a little thought as to how precedence should be handled (what if the appimage also provides plugins installed on the system, which copy should it choose) - but probably it should just respect environment variables which the user has already set (like LADSPA_PATH and FREI0R_PATH, and if the user sets them then it’s their responsibility to set them correctly). If it does that, then people can opt into whatever additional plugins they like (including private ones they wrote themselves) even if the kdenlive developers don’t want to commit to maintaining them in their default build tree.

Having an easy way for users to build their own appimages identical to what the kde build farm does would be icing on that cake, but again that’s beyond just what you’re wanting immediately here.

Hope that makes the puzzle pieces start to fit together a little better for you.

1 Like

Hello @Ron
How wonderful that you take the time and energy to give us all this information, which really helps to better understand open source, Linux and Kdenlive. I can benefit a lot from it. These thoughts also give me some peace of mind because I now understand better why things are the way they are with the AppImages.

Of course, I don’t have a (simple) solution for how to get the desired plugins into the AppImage. But it is very reassuring, because I only need the AppImages if the normal Kdenlive fails. So far, I have usually been able to get by with a downgrade.

Since I don’t know anything about programming, I don’t try to manipulate the AppImages.

I think it’s great that you’ve written a few things that everyone uses in Linux today. I thank you for that alone.

What surprises me a little, however, is that you keep all the AppImages in case you need to edit or render an old Kdenlive project again. Is that really necessary? I can access my 3-year-old .kdenlive and edit it as I like - I’ve never noticed any problems.

And, thanks again for your comments.

You ask good questions, so helping you see the bigger picture means you’ll ask more of them!

Most of the time returning to an older version of kdenlive isn’t necessary, but over the years there have been occasionally incompatible changes and support for some things dropped as better ways to do them have evolved.

I’ve found it’s mostly pretty good at updating a config to work with the latest version, but if something the project used is no longer available, or behaves differently, then you need to re-edit the project to do whatever that was in some other way. If I was doing a major re-edit of some older clips that’s probably what I’d do - but if it’s just to re-render it with some tiny change, then using the version it was originally created with should be able to do that without any surprises.

That sort of thing has been happening less and less often, which is a good sign of things maturing in good ways - but keeping the old appimages around consumes an almost insignificant amount of disk space compared to the clips that have been edited with them, so it’s pretty cheap insurance for being able to revisit archived projects (and sometimes for checking if some problem I find is actually newly introduced, or just newly noticed by me).

1 Like

I can well understand your arguments. Because I now understand them, it’s easy for me to decide not to keep the old versions for myself.
If I’m reworking an older project, I don’t mind working with the latest tools in case an older one fails.

I am very reassured.

Regarding my initial questions: It has been clarified that only the SWH plugins are missing, the rest are still there.
What can I do so that these SWH (which contain very good audio tools) are also integrated? Or is it more sensible not to burden the developers with this request?

It is one of the ways the appimages can do something distro packages can’t easily. Rewinding my distro to 2019 kdenlive is not as easy as just firing up the relevant appimage.

There’s basically two options for what you’re asking for:

As Bernd suggested, make a feature request to include the extra plugins you want in the default build. That might depend a bit on if they are licenced suitably, and build easily and cleanly.

Or make a feature request to support system plugins from the AppImage. That will fix the problem for any extra plugins that people might want to use.

I’ll probably do something like the latter once I get back to playing around with gyroflow again and figure out all the things that need more tweaking for it.

To give this some technical context:

For the binaries we build with Craft (AppImage, Windows and macOS) for ladspa we have ladspa-cmt, ladspa-tap and ladspa-rnnoise enabled. Ladspa-swh has been disabled 2 years ago by this commit: Update (913ec670) · Commits · Packaging / KDE Craft Blueprints · GitLab with the comment “ladspa-swh currently breaks MLT, making render impossible. So disable for now”. This might have been fixed in the meantime, but as I don’t know the details of how it broke MLT I don’t dare to re-enable it without deeper testing.

1 Like

Ok, if you have removed SWH-Plugins because there were problems, then of course I don’t want to suggest just putting it back in.

Are there always problems with SWH and MLT when the plugins are installed or only when they are installed in Kdenlive? I ask because I always install this plugins, and I haven’t noticed any problems. I rarely experience crashes from Kdenlive on Manjaro Linux.

I know that these plugins from Steve Harries’ are very old, but they are still indispensable. The very best compressor and a the best equalizer.

If I understand you correctly, it wouldn’t be a good idea to open a feature request for them now.

I can live with it as it is now.

What do you suggest now?

The only information I have about this is the commit I mentioned above. I do not know the details of the issue we experienced two years ago and I fear Jean-Baptiste does not recall them either after such a long time. However since the Flatpak and other Linux setups (like yours) have the SWH plugins enabled I guess the issue was specific to either macOS, Windows or AppImage packaging or the Craft system.

The way forward would be to create test binaries with SWH plugins enabled and test them on all platforms (Windows, macOS, Linux) and different scenarios like with a project that uses effects from the swh bundle as well as with a project not using them and check if eg. rendering works. If all tests work well we can generally enable them again.

This is will be some work. If the render test suite would be in a better state content wise this could have been done mostly automated, but unfortunately it isn’t yet. However I think your request is closely related to the effects workflow topic we are currently working on so there’s a good chance we will look into it soon. I just put it on our list.


It’s all good, I’ll wait and see how it develops.

I could do the tests, but only on Linux and Windows, I don’t have a Mac.
Would that be any help?
But if there are other, important tests: I’d be happy to do elaborate tests - because Kdenlive is so important to me and I’d like to contribute to its success.