It would be nice to be able to make and share plugins. Lets say we want to add some sort of automation, effect maker or add an AI model integrated into the system.
There are effect templates, but I donât know about anything more advanced.
1 Like
Add-on integration is something Kdenlive team is thinking about. But the integration is not easy at the moment. Other aspects are security reasons which we have to check.
3 Likes
@Eugen_Mohr Sorry for late reply; I love kdenlive but the only problem Iâm facing is the fact that we canât make custom effects but only presets. I use templates but sometimes I have to resize them etc. I have to use lightworks (as it is available on Linux too and has custom effects not presets).
1 Like
I just reviewed Kdenlive Roadmap - Kdenlive
Under âLong termâ I find
Scripting support (eg. Python API)
I reaaaaally think this should have a higher priority, as it would enable the community to contribute in a completely different way and thus make kdenlive more competative. Especially in this time of AI-tooling not having api/scripting/rpc/plugin is a bottleneck. I can imagine all kinds of tools popping up around kdenlive if there would only be a way. And it may offer an alternative resolution to many of the other issues listed in the roadmap (some may be solved as community plugins, at least as an intermediary or prototype solution).
I understand that it is a question of resources but I just want to present the viewpoint that scarce resources is just another argument why this should be prioritized, over adding other new features in the core software. Ideally, kdenlive would be as extensible and customizable as possible. This would be a competative advantage to other closed products.
Just look at neovim!
(PS. Lua may be a good alternative to Python)
But would it? Would it reaaaaally?? What exactly are you wanting to contribute which could only be done this way?
A bottleneck for what? Thereâs a lot of buzzwords squeezed in there, but how could we possibly design a useful api/scripting/rpc/plugin without even a single concrete example of what you want to use it for?
There are ways, and they have. What kind of tools are you imagining that there currently is no way for?
Which ones?
Then youâre way ahead of me on this and youâre going to have to bring the rest of us up to speedâŚ
If I was to drop everything on my current todo list and make âthisâ my highest priority - I still have absolutely no idea what you reaaaaally want to do with it, whether any of what youâre imagining is actually possible to do in kdenlive (as opposed to in some other part of the toolchain), or what you imagine would make things easier or more accessible than the ways in which they are currently already possible for people to do themâŚ
Why do you say âideallyâ? Itâs open source software with a CC-SA licence - you donât really get more âas extensible and customizable as possibleâ than that.
It is.
For what? Which image processing tasks do you think an interpreted script language might be a good choice for?
1 Like
Kdenlive will never be able to compete with the big, absolutely professional editors, and it doesnât have to.
I think the creators and the community need to ask themselves where they want to go.
The most important thing for me would be that Kdenlive is stable. What I need is reliability. Since it is an opensource software, I donât want to make any demands, but rather be grateful for what it can and offers.
Reliability is 100 times better to me than lots of new features that are great but donât work 100%. There is no alternative, especially for the many Linux users. And thatâs why quality should always come before quantity.
The top priority should be that you can make and render your project at any time, without the nasty surprises because something new is nice but doesnât work.
1 Like
I get your sentiment here - but I wouldnât go so far as to say that ⌠thereâs no fundamental reason it canât, and for many people it already does.
I agree we donât have to treat it as a competition though, it can become best of breed and implement good ideas on merit, not just because Someone Else Does Them.
And Iâm not at all saying we shouldnât be talking about ways to improve it. All Iâm saying is that âIt needs more ponies, ponies are kewl!â isnât really a very actionable request.
If someone has a real use case for a thing theyâd really benefit from being able to script. Or a real idea for some class of plugins, that isnât already possible via the several plugin mechanisms already available. Or something like that. Then we can have a discussion about what options there are, what might need to be done, what the pros and cons are, what a design might look like, what functionality it must provide.
If nobody can think of a use case that isnât entirely handwavy, entirely contrived, entirely unrealistic, or entirely a cloud of If We Build It They Will Come pixie dust - then weâre still a few steps short of knowing what problem this might be the Perfect Solution to.
Picking a language at random most certainly isnât the first thing that needs to be done.
42
1 Like
LOL. Wish it was that easy 
FWIW, what lightworks does, does seem to be a nice idea. In addition to letting you save effect stacks like kdenlive already does, it lets you define your own pixel shaders that run on the GPU.
Which isnât quite the same thing as âcustom effectsâ, but it is a good and logical place to âplug things inâ with a well defined interface.
This is how movit works - and I donât really know what the ongoing issue between it and mlt is, but if that is solved, this might actually be a good thing to have on the roadmap.
Can anyone tell me what short, mid and long term means in the kdenlive roadmap?
Please note that there is one main developer with some code contributors few and far between. So, depending on the complexity of the task it can take longer than anticipated. Also, keep in mind that the roadmap may change, and something that was planned mid or long-term may be moved up, and vice versa. But generally speaking, short term means itâs planned for the next 2-3 releases, mid-term 3-4, and long-term 4-5. Releases are .4, .8, and .12 in the yearly release cycle, i.e. 25.04.0 is the next release and also the first one in 2025. There are bug fixes that are released in between releases and are simply a sequential number in the last digit of the version (e.g. 24.08.3).
One plugin idea that I would love to see is an Audio-Reactive image plugin. Nice and simple concept: Taking an audio clip (not the Master) and making a separate image react to it. Similar to what Discord does in voice chats where it lights up who is speaking.
Problem: It is impossible to know which combinations of preset effects will allow me to have that completed composite.
With a scripting plugin system, I could actually build that reactive Image effect without having to hunt, peck, and pre-process audio just to get it to show up in my project monitor.
I know thereâs much more to adding that type of system than what I am aware of. So security, reliability and many other factors would require awareness before publishing that type of add-on to an already-stable program.
I mentioned this already, (regarding lua) last year.
https://discuss.kde.org/t/feature-request-use-lua-scripts-as-plugins-to-automate-small-tasks/14019
Also here too
https://discuss.kde.org/t/clip-bin-job-create-job-to-change-duration-of-image-clip-s/12424/3?u=sherkhan30452
And I understand the situation, so I am not asking again.
I tried to do automation, but using 3rd party software.
I do understand that my question could come across as "oh just give me more shiny things". And as I said, I understand that in this kind of project time/energy is scarce and have to prioritize wisely.
I wasnât however prepared for the level of push back.
Of course it would have helped if Iâd presented some concrete API/plugin ideas. Of course. But I didnât do it as I thought âhey, shouldnât it be fairly obvious that an API would be used in many ways probably not anticipated right here and now?â.
And also there is this AI-thing going on in the world right now.
I have a lot of issues with the AI-hype and its impact on society, democracy, sustainability etc. But even more so I want not-for-profit driven organisations such as KDE and projects like Kdenlive to succeed. And without any doubt, AI-integrations will be the norm eventually and it is already starting.
There is now a new open standard that has emerged and is being embraced that addresses the question of how to integrate LLMs with software and services. It is called Model Context Protocol, you may have heard of it if you are a developer. It relies on a server <-> client relationship where the server is the thing which has capabilites (resources, tools, prompts) and the client is perhaps your terminal AI assistant, Claude Desktop or whatever you use to interact with your LLM.
I use this on a daily basis as a developer, not like a naive âvibe coderâ doing things to show off on youtube, but rather as a practical helper assistant and extended brain for suitable tasks which are within reach.
MCP-servers for software are now starting to pop up here and there. This includes 3D-modelling program Blender (by the non-profit Blender foundation) and commercial competitors in the video editing space such as DaVinci Resolve.
I have no idea how capable these early implementations are at the time of this writing, but they do define a new world where all kinds of software will start to share a common way for enable interaction though human natural language. This can be written - or perhaps more commonly down the road - spoken.
I push this issue not from a point of an immediate need, but rather as an early signal for what is coming and with a sense of urgency in terms of starting to explore that path. You say that the current infrastructure is an obstacle here, making a public API/scripting harder. Well - isnât this just another reason to start looking at this sooner rather than later? The process itself doesnât have to be rushed, but the direction is important I think.
Why / how this matters to me personally? Well, Iâm a jack of many trades. Which means I also donât have the luxury to only work with one thing, eg. video-editing. I jump between disciplines in my daily work. At the same time Iâm an engineer and I like working with proper tools whenever possible. And - from an ideological standpoint - I want to use FOSS and / or software from non-profits (even if it is paid). Therefore Iâm here, in this forum.
But I will never be fluent / expert in Kdenlive. So therefore a human language interface would be useful / helpful (i can also imagine other automation helpers for my kdenlive work, eg. importing and using assets a lot more easily). And I donât think the proper way to do it is to develop it yourself, but rather just expose the functionality and let users leverage whatever AI-toolchain they have available - today or tomorrow. The alternative is that Kdenlive developer team itself takes on the task to provide all these features and I donât think that is neither the best outcome/UX nor resource effective. Use standards.
This isnât about today, it is about tomorrow and where things are heading.
1 Like
If the collision between reality and dreams is âpush backâ, then ok ⌠but thatâs not what I would have called it. Iâm sorry if I came across as a bit brutal - but it seemed appropriate to be very specific about how you might make more practical suggestions if the overarching theme of the problem was that you were being inactionably vague and/or impractically romantic about what you actually wanted to do.
And what if one of the âunanticipated waysâ is just people wonât use it at all, and it wonât actually solve any of their Real World problems?
Because thereâs actually evidence for that outcome. Thereâs been a plugin API for effects for a very long time. And a completely open âAPIâ that can Do Anything. People saying âI canât do X with that interface, even though Iâve tried Y and Zâ have an actionable problem.
âI canât even imagine how this might be used yet, but it needs pluginsâ is mostly just a big red flag on the road to a very poor design. I want world peace is a lovely dream, but neither that nor âyou just need to be nice to each otherâ is an actual plan for how to achieve it.
Thatâs not a standard, thatâs a github project. And a volatile and experimental one at that.
No actual problem, and no actual experience with, or research into, the proposed solution isnât really the usual foundation for a successful and useful API. And Iâm not having a dig at you there. Itâs just that Iâve designed and deployed and been on point for maintaining enough of them to know that it is always a mistake to try to implement something speculatively, that you personally have no use for and that nobody else has ever detailed a specific use case for.
If you ignore that and do it anyway, you will just create something that works well for nobody at all. And if or when the first real user actually makes themselves known, their real world requirements will need it to work differently, except now youâll have a legacy mess getting in the way of doing that well, which if you change then someone else will come out of the woodwork to say âhey I was using that in a dirty hack of my ownâ⌠cf. xkcd: Workflow
Thatâs a dark alley you really donât want to go down without a torch.
what functionality, and how?
Itâs all already exposed in C++, and some is exposed though a variety of other interfaces. There is no conspiracy to hide the functionality which we just need to remove.
If none of those work for something you actually want to do, then itâs useful to talk about what you want to do and why they donât do it. Itâs not about whether itâs in the sooner or later to look at column in the road map, so much as there simply being nothing to look at if there is no concrete use case. The first step in being able to use human language to âsolveâ a problem is still going to be finding the human language to actually define that class of problems to the other humans who you are hoping will implement it for you in a way that itâs actually possible to implement for that particular use.
And really, if your use is âI want an effect that flashes the screen redâ, the best answer is almost certain not going to be âwe should implement a general purpose NLP oracle!â. A large part of why people coming from other software to kdenlive find it so nice to use once they get over the small muscle memory differences is precisely because the implementation is being driven by real users and real use cases, and not by speculation on what Killer Feature might be The One to make it the leading marker leader in market leading next year with big bonuses for all the executive staff.
Itâs not push back to say âwhen you have a real problem today, it will help everyone much more to tell us about thatâ.