It might be nice to make that a ‘toolbar’ like the timeline one, that people can customise. But the current default makes use of all the available space, and I’m not sure what you might usefully fill the otherwise wasted space with if you rearrange it?
1 Like
On Windows I have a ShuttlePro which works natively with Kdenlive even the jog shuttle for fast forward and rewind. The ShuttlePro recognizes Kdenlive (or other focused programs) and changes the behavior. The ShuttlePro only send keyboard shortcuts to Kdenlive. You can even send sequences of shortcuts to execute tasks like above about ripple trim.
The question is, if your mouse “sees/recognizes” which application is in focus and changes the behavior accordingly. If yes, can your mouse send keyboard shortcuts?
I think with something like this it can …
For Linux there is Input Remapper. Just tried it and could assign Shift+R (cut clip in timeline) to the middle mouse button. Works like a charm. Still, I think Kdenlive should be able to do that natively but until we can implement that these two tools are possible stop gap solutions.
We don’t implement the keyboard remapping, we just use it and it lets us customise the key → action relationships.
There is no such mechanism for mouse button handling.
So how are the clicks and scrolls being interpreted? I’m confused …
As mouse actions. A “mouse” is a generic device type, so is a “keyboard”, they are handled by different device drivers, have different capabilities, and are handled as entirely separate entities with entirely separate idioms as to where their events get delivered, interpreted, and processed.
There are some devices that can operate as both, but to do so they advertise that they are both and act that way as two completely independent devices, even if you plugged them in with only one cable.
(and we’ve now wildly diverged from “title tool improvements”, so I wonder if some of this shouldn’t be split into separate topics because it’s getting harder and harder to find the actionable bit needles in a roiling haystack ocean of confusion over what is or isn’t practically possible ; )
Open this new topic
The grey bars are there on purpose.
If I make the left sidebar much wider it does shrink the grey bars but then I have the time line left aligned with the video preview right aligned. There’s a big disconnect in where my eyes need to look and I only have a 32” monitor (it would be amplified with a larger monitor).
Having it padded by grey bars lets the video player be closer to the center of the screen and when I’m doing cuts, usually I’m near the center of the timeline or at least somewhere in the middle 66% of the timeline.
This lets me quickly glance up and down with my eyes instead of shifting them to the edges of the screen. For an action that happens an uncountable amount of times per session this optimization is well worth it.
It’s not something I’ve optimized on purpose. It was an intuitive thing and I only realized how disruptive it was with the default layout.
It doesn’t have to do with not learning. Double loading your left hand while your right hand sits there doing much less work is inefficient no matter how you look at it.
I think to be fair, this should be slightly modified to say it’s not how mouse actions currently work in Kdenlive.
Other programs have exposed action binding in a way where keyboard and mouse buttons can be bound using the same UI as an end user. How it’s implemented internally within code is an implementation detail that’s not leaked to the user.
The complexity is hidden and the abstraction allows for flexible, predictable and easy to use action binding. The UI prompts the user to pick an input and you can either click a mouse button or press a key combo to set it, with or without modifiers for both types. It does what you expect as a user.
Major browsers for the last ~25 years have supported thumb buttons to go forward and back. It’s not a standard in every app because all apps do different things. It’s not a specialty device, it’s a basic wired USB Logitech mouse with 2 buttons, a scroll wheel and thumb buttons.
I like to take advantage of these buttons in apps that support them. This goes for the OS too, the window compositor I use (niri) supports them which lets me assign global behaviors to them when combo’d with the super key.
Not at all. Left clicking can work as it does by default. Right clicking can work as it does by default. The wheel can work as it does by default. The thumb buttons can remain unbound by default.
Then users can go in and customize any of these if they want to deviate from the defaults.
If down the line based on user feedback you determine a majority of users are doing XYZ with those buttons then you can assign them defaults, and if users don’t like those defaults they can overwrite them.
This is a tried and true model of binding inputs.
Can you give me an example? I can press 2 buttons in serial, as in, 1 after the other, this isn’t a skill problem. It’s a problem in that my left hand has to do 2 things while my right hand sits there idling. Having both hands do something is much less cognitive load and faster. It’s also on the hottest path of editing (at least for me), cutting and extracting.
What factor would my desktop environment have on this? I am using niri and built up a DE around it using other popular tools but ultimately niri spawns Kdenlive into a window and I typically keep it maximized while editing.
It’s a heavy keyboard focused set up but with lots of mouse support too.
Yes, I am all for this and that’s what I have been doing but I’m at the point now where I’ve run into scenarios that are simply much slower.
There’s a lot of things. The video I posted above shows a bunch, but I will mention one here. Deleting unused tracks and media. Camtasia has a way to do this in 1 click. Kdenlive does not. Prior experience and habits have no impact here, it’s simply a difference in features. It’s not major because it doesn’t happen a lot but this is a death by a thousand papercuts type of thing.
Another one that I didn’t mention in the video is the timeline. The timeline is a sacred spot for screen real estate. Having it as wide as possible with a good enough zoom level to let you make accurate cuts is important right?
But Kdenlive puts the audio mixer, effects stack, time remapping and subtitles there which take up a decent size portion of that space. Ok, so you can goto the view menu and turn all of them off and now you have your full time line back.
But being able to quickly view and edit your effect stack is really important. How can you edit them without it being in the bottom right which immediately takes up timeline space and has a minimum width? Is there a way where I can put the effects stack in a different dock area? There’s 2,000 pixels of empty grey space, that would be a great spot if I can set up a custom dock. If not, how about at least nested up top in one of the other docks?
I didn’t see options to let you arrange what goes in each dock.
I’ll answer one of my questions near the end since the forums aren’t letting me edit it.
Turns out you can undock these windows and then float them anywhere you want, such as over the empty grey area or a second monitor. That works really well for solving this problem.
I haven’t used Premiere but Camtasia kept it centered too.
With a 4k monitor at 1:1 scaling, the audio mixer currently fills up a lot of horizontal space.
Making it optionally vertical sounds good at a glance, especially if it’s only taking up space above the timeline, such as where the video preview area is contained to. This avoids it ever taking up space down below and like you said, lets you center align the rest.
One thing to be mindful of is keeping the current time 00:00:00 near the play and stop buttons feels like it would be important. If you press stop, there’s a reasonable chance you’ll want to see the exact point you’ve stopped at. It helps minimize eye movement.
How do you move the play head accurately without using the mouse?
My normal cut and ripple workflow with Kdenlive has been this:
- Look at the audio in the timeline for something I want to cut (dead silence, I coughed, loud breath, etc.)
- Click this spot to move the play head where I want the cut to start
- Press
Xto make the cut - Look at the audio in the timeline on where I want this the 2nd cut
- Click this spot to move the play head where I want the cut to start
- Press
Xto make the cut - Click the mouse into this new clip that was created from the 2 cuts
- Press
CTRL+Xto perform the ripple delete
With Camtasia it was this:
- Look at the audio in the timeline for something I want to cut (dead silence, I coughed, loud breath, etc.)
- Click this spot to move the play head where I want the cut to start
- Since the play head has little handles to drag left / right, I’d drag it to where I wanted the cut to finish and it becomes a dynamic range of time that’s selected
- Press
CTRL + Xto perform the ripple delete
As you can see there’s half as many steps and it lets you use both hands equally. More importantly, the cognitive load is super low because 2 of those steps are just looking at something to make a decision, it’s not micro-managing the UI.
It’s well optimized because your eyes, left hand and right hand all work together almost in parallel. I covered this in the video linked above btw.
I’d love to be able to find something comparable in Kdenlive. I know it won’t be the exact same, but something that gives the outcome of close to zero mental load and twice as fast as the current set up.
I checked the docs based on what you suggested but it says:
-
enable ripple
-
place the playhead at the desired place
-
hit (: This cuts and removes the clip and space to the left side of the playhead. ) does the same but to the right side of the playhead.
I am not seeing how that is applied to this use case you described. I opened a video to experiment as well. What am I missing here?
I don’t think so, it’s a really bare bones Logitech G203 mouse. It has no special software. Whatever Linux kernel drivers are loaded is what’s available. I used ratbagctl to turn off its RGB lights.
I am using niri which is based on Wayland. berndmj’s suggestion of Input Remapper should be workable.
I think that qualifies as self-harm, and not something Kdenlive inflicted on you …
Turns out you can undock these windows and then float them anywhere you want
Which it would have taken less time to read all about than it did to tell us all the ways that not doing so was unsatisfactory for you, and rationalising the mistakes you made as an ‘optimisation’.
“intuition” is a poor substitute for understanding. especially in an unfamiliar environment.
It doesn’t have to do with not learning
I think it’s pretty clear the above most certainly does. As does quite a bit of what follows it.
I think to be fair, this should be slightly modified to say it’s not how mouse actions currently work in Kdenlive.
Reality has never made any promises about being fair. So if you want to be accurate this isn’t something kdenlive implements, or something you could claim that narrowly with a straight face. If you want to rewrite the entire stack to work the way you imagine, knock yourself out - but that’s not the way that what we have to work with works.
The complexity is hidden and the abstraction allows for flexible, predictable and easy to use action binding
Spoken like someone who has read a book on software design and imagined how it could be implemented instead of looking at the code and or reading the documentaion to see how it is.
But hey, when you write your own abstraction for this, you should use that in the marketing for it. Middle managers love buzzword filled cliches like that.
It’s a problem in that my left hand has to do 2 things while my right hand sits there idling.
Then you’re still doing it wrong, and I’m honestly not quite sure what you’re still missing from the clues Eugen tossed you on this, but there are several ways to do that sort of thing with much less work that you currently seem to be doing, and which to choose entirely depends on what else you are also doing at the time.
Deleting unused tracks and media. Camtasia has a way to do this in 1 click. Kdenlive does not.
How do you move the play head accurately without using the mouse?
I’d love to be able to find something comparable in Kdenlive
Are you starting to get a sense of where you might find these things?
And how to ask about what you don’t know instead of telling us all the things you did wrong because you didn’t know, but are pretty sure you’re right about because you’re pretty sure you can trust your intuition and don’t need to fact check these things.
And I’m sorry if that all sounds a bit harsh - I really don’t want it to, and I’m sure you mean well …
but this is getting a bit repetitive with you telling us things you haven’t fact checked, that clearly aren’t true, and then telling us we’re wrong when we try explain how they really work and what is really possible, and that you really really really aren’t doing yourself any favours by thinking you have far too much experience to bother reading documentation and learning how things actually work.
I’m certain, that at some point, you will have some insights that will have more value to more people than just getting some personal frustration off your chest, and I look forward to that day. But right now you’re doing a lot of swinging in the dark, and each new swing seems to hit less things than the last did.
So maybe go read the docs. Then go experiment with some of the things you discovered in them. And then if there are things in there that aren’t clear, or that you still don’t understand, or that you still aren’t clear on how to do, start a new thread for each separate problem and ask for advice or clarification.
Because if the docs aren’t clear, fixing that is useful. If some problem really could be solved some better way, discussing that is useful. But having to rebut your imagination, in an increasingly long and wildly unfocussed thread, when it has little to no connection to the reality that applies here is just going to give some poor AI scraper absolute nightmares when it tries to make sense of All These Words. And that’s not really helping anybody.
I love that you’re keen to fix and improve Best Practice wrt Kdenlive. But to actually contribute to that usefully, first you need to spend the time and have the patience to learn what it actually is.
Also add an ability to do Undo/Redo in Titler. This should be a standard thing.
1 Like
Undo/Redo can actually be surprisingly hard to get right (and getting it subtly wrong, which is really easy to do and not have any clear warning about, might well be the #1 cause of the ‘random’ crashes that some people sometimes see, and they can be extremely hard to pin down and debug even with a backtrace unless you have a perfect sequence of actions that will always reproduce it).
And the title tool is old in the grand scheme of all kdenlive evolution, so it’s not entirely surprising this didn’t get retrofitted into the actions inside that dialog itself (which is a separate challenge, because it would need to be totally independent of the ‘normal’ undo stack used by the rest of the app, since you can’t ‘undo’ closing a dialog, and normally wouldn’t want to anyway).
But you’re absolutely right that this is another glaring omission (among many) in its current capabilities - and probably Yet Another reason why dabbling around the edges with this is time that would be much better spent on investigating and supporting a more modern solution with the kind of capabilities that have become the norm for titling in professional productions these days.
Are you suggesting I use the arrow keys to move 1 frame or 1 second at a time with the keyboard instead of using the mouse as the most efficient way to make cuts while watching a clip and editing it at the same time? That is what the docs say about using the keyboard to move the play head.
You are making a lot of assumptions btw. I think it’s probably best for me to stop replying. Thank you for the help.
I’m suggesting that you really need to read and understand the documentation before you come to more wild and incorrect conclusions about what Kdenlive can or cannot do. Relying on just your “intuition” has very evidently not been helping or guiding you well here.
And that if you want to have a meaningful conversation about best practice and possible ways we might improve it, that first you need to understand there are lots of ways to do most things in kdenlive, and the true key to productive and least effort editing is to know which one to choose when. Not to teach your left hand how to stab just two buttons and get sad that some things are harder then they could be with such a limited repertoire. And not to move the wrong button for the job to a more valuable piece of the UI real estate because you haven’t yet learned it’s not really the primary interface for non-novice users. And definitely not to assume that in the more than 20+ years of collaborative development and user feedback that has shaped things into the way they are today that you’re the first to think about and really understand most of these things, or that you really understand how they got to be that way and why in the first place, or the pros and cons of all the alternatives that have previously been considered, or the constraints on what alternatives may be viable.
Which is not at all to say that we are not interested in hearing your perspective on things. But if it’s not an informed perspective, then kind of by definition it’s a lot less likely to be insightful except by some complete accident.
You are making a lot of assumptions
And believe me, I have been revising them every time that it became apparent that something I had assumed you already had some understanding of was in fact still a complete mystery to you.
There is absolutely no shame in being a novice. But the real secret to growing beyond that is recognising when you are and when your ‘intuition’ isn’t actually “unconscious competence” guiding you - but is instead a big dark blind spot you need to shine some light and conscious consideration into.
I think it’s probably best …
And on that I think we agree completely - we’ve gone way off topic from “The old title tool sucks and should be better”, the essence of which I think nobody disagrees with (and also isn’t really breaking news : ) - and not in a Lost In Being Productive kind of way, so it’s fair to say hope for that seems to have been exhausted.
But I absolutely meant what I said above. When you do start working your way through the docs, and you do start to get some experience with things that you haven’t even suspected exist yet - please do feel absolutely welcome to open a topic here to discuss anything that’s not clear, or could may be made clearer or better or grow some sibling functionality that might also be useful. Let’s just try to keep them a bit more focused to just that one thing, and not let them become a fruit salad of free association that nobody is quite sure what to do with at the end.
Thank you for the help.
You are absolutely welcome, and I do mean that absolutely unironically. I hope with a bit more practice and an open mind to alternative workflows that things really do start to come together more fluidly for you.
And of course that we find a Really Nice Complete Solution for the next generation of title tools.
Thanks, I meant mine sincerely too.
I mean, I’ll continue using Kdenlive. No hard feelings. I’ll keep what you said in mind about future threads / conversations.
Hello – I agree a good Titler function would be a great improvement. I think time on this would be more important than all of the sub-title work. When I used to edit on tape, my titler was an important piece of equipment (and cost a lot). A good titler would save so much time and improve the quality and professional look of our projects. Cheers ===
They are two independent things with entirely different use cases and shouldn’t be conflated or confused with each other.
You shouldn’t be using closed caption subtitles as a replacement for a proper titler, and you can’t use ‘titles’ as a replacement for closed caption subtitles.
Personally, I have a need for both, and a major patch in progress to significantly improve subtitle handling. I’ve been a bit hijacked by other projects I need to get finished first, but I hope to complete land that before too much longer.
A good titler would save so much time and improve the quality and professional look of our projects
I absolutely agree and feel the same - which is why I think this needs more than just some dabbling around the edges with “UI improvements”. Modern titles are so much more than just “slap some text over the top and maybe make it scroll” - doing them well really is an entire (ongoing research and development) project all of its own, and I think we’ll get the best results by figuring out who is already doing that well and leading in that space, and finding a good way to seamlessly interoperate with that.