TL;DR - Having an effect that could be placed on a clip in the timeline that generates text with all the property options available in the title clip (font, color, size, line spacing, alignment, etc.) without the need for a title clip would solve all my issues with kdenlive. Also, I make lyric videos. So, lots of text on screen might be bigger deal to me than most, but it is a massive bottleneck for me.
In the few months I’ve been using it, Kdenlive has been awesome in every way except for the way that text is handled. I hate using the title clip because of the inherent limitations it has. You can add lots of text to it, however the requirement of using the viewport makes this limited. You can change the size of the viewport, however you need to do it for the start and end of the clip, then you have to go through the extra steps of transforming the clip to match in the timeline, which always leads to feathered text due to the distortion. The workaround for this seems to have always been “make a PNG of the text and import that”, but what if I need to change the text after making a bunch of transformations on the timeline? I’d be out all that work and I’d still have to use another application to just edit text.
If you look in Effects there is “dynamic text” and “GPS text”. Both of these display text on top of the clip they’re dropped on and that text is editable, however neither of these are meant to display lots of text. So text via effect instead of clip already exists. If you took that idea and gave it the options that the title clip has and let it display as much text as the user wants then every issue I have with kdenlive would be resolved. I could use that to go over a transparent color clip (or any background for that matter) and I’d be perfectly content.
Searching around it seems I’m not the only one frustrated by the way text is handled in kdenlive, but I haven’t seen this option discussed.
Can you describe what you’re doing that makes this a problem a bit more specifically?
I don’t see how making an effect, that in effect, behaves “just like the titles do” would change anything you’ve talked about here. You’d still only have a viewport the size of the clip the effect is on to work with.
I’m not saying there aren’t lots of things that could be improved with title clips, and it would definitely be useful to enumerate the needs and use cases for those explicitly - but I’m not seeing how any of what you described here would be improved by making them an ‘effect’ that is dependent on having some other clip to be applied to, instead of (as they are now) a discrete thing that can either stand alone or be composited on to any other stack of clips and their effects.
What do you want improved that can’t just be improved in the title clip tool?
Can you describe what you’re doing that makes this a problem a bit more specifically?
This is easiest to do with a video. Unfortunately I cannot share links to anything so I’m not sure how to best illustrate this problem. If you want to know my specific intended purpose, I make simple lyric videos and my workflow has always been to make a single clip of the text, animate it, and mask out what I don’t need. This is possible if I use a png of the lyrics, but if I messed up the lyrics or music cues anywhere then all my work has to be deleted since I can’t edit it. It’s an issue I’ve only ever had in kdenlive.
What do you want improved that can’t just be improved in the title clip tool?
Perhaps this could be possible. Allowing to view the overflow from the title clip would pretty much resolve this. But from my perceptionof how the title clip works - and correct me if I’m wrong - I feel like this would require fundamentally changing the title clip as it would remove the entire viewport from the title clip editor. But also if the animations of the text were limited to the animation tab in the title clip editor that would restrict what would be possible from the timeline. I just get the feeling that I’m butting up against a feature that is very useful but too focused for what I’m trying to do.
I’m still not clear on how you’re displaying the lyrics - are you just scrolling the (masked) wall of text in the style of classic movie credits, or something else?
Or why if you can do this with a png, you can’t make the same sort of thing work with a title clip?
If you hang around on the forum here, and read and interact, you’ll get permission to post links pretty quickly - but I don’t have privileges to escalate that privilege to you, sorry.
What do you mean by “the overflow”? I gather you know you can animate the viewport to ‘scroll’ the title text that is visible at any point in time - or can create multiple title clips for each portion of the text.
If you’re trying to mash the whole set of lyrics into an area the size of the viewport in a tiny font, then blow that up with a transform, then yeah, I wouldn’t expect that to end well - but I’m (still) having a hard time imagining what you’re doing / how you’re doing it, that wouldn’t work with one or more title clips providing the text, sorry.
I agree in principle but Kdenlive treats a title clip differently.
You can create a textbox in the title editor that overflows vertically. But when put into the timeline, Kdenlive cuts the title clip to the project dimensions, so even though you move the title clip for scrolling purposes it moves the clip showing only what is visible in the non-zoomed title editor.
You could play around with the start and end viewports in the title editor but that triggers an animation that cannot be adjusted: it simply scrolls the title’s objects from start to end viewport over the duration of the clip in one smooth linear motion. This is not always what is needed.
The title editor “knows” that there is a text box longer/bigger than the viewport and creates scrollbars. If that “knowledge” were used when displaying the clip in the project monitor the OP’s problem were solved.
There is a chance that once Kdenlive doesn’t squeeze clips into the project resolution anymore (is on the roadmap) a title clip could be longer/bigger than the project dimensions and scrolled using Transform.
Create the title clip with the lyrics, allowing overflow
Do this with a readable font size
Once finished reduce the font size so that the text box fills the title editor’s viewport (the text might not be readable anymore now)
Add a Transform effect to that title clip in the timeline or in the bin and adjust the size and position so that the text is readable again (like back to what you wanted before)
Now use another Transform effect (or the same one, your choice) to keyframe the animation
@berndmj Yes! I think you’ve grasped what I was having trouble putting in to words!
Add a Transform effect to that title clip in the timeline or in the bin and adjust the size and position so that the text is readable again
I’ve found there’s actually a “better” way to go about this that’s a little hacky. Since I can’t share a link at the moment I’m going to throw a portion of a youtube link to a video I recorded to illustrate why even this solution doesn’t really work. It’s at the 3:00 mark.
@Ron Below I’ve got a partial link to a youtube video I recorded to illustrate the point I was having trouble making. I think this will address everything you’ve asked and addressed. If there’s anything you’d still like cleared up please let me know. I want anyone who might work on this software to also have a clear picture of this.
There is some scope for ‘adjustment’ there, in the sense that you can create multiple title clips and composite them all together to get more complex sequencing and animation. And the overflow/animation can be in any (single) direction, not just vertical.
But yes, it is more limited than transforming a larger image, but that has its own problems (cf. the post about ‘jumpy’ sub-pixel zooming), and the issues with font aliasing etc.
I was guessing the OP had tried something like this when they talked about “feathered text” …
but I’m still struggling to picture exactly what animation effect they are after with the lyric overlay.
Yeah, that shows what you tried, and why that did not work - which I did mostly already get a sense of - but what I still don’t have a sense of is what the final effect you are looking to achieve looks like …
So we still sort of have an X/Y problem, where you’re asking “how do I use method A to do B”, and it’s reasonably evident that A is the wrong tool for the job, but we can’t tell you what the right or best tool/technique in kdenlive might be until we know what B actually is
can you toss us a link reference to one that you’ve already done, or one that someone else has done which looks like what you want to be able to do?
Sorry for the slow response. Yes I can give you a link to a video I’ve done. This is one I actually did in Kdenlive using the PNG method: /watch?v=FnUvSL57E2I
I’ve had other ideas that I think would be useful with a text effect instead of a text clip though, fwiw. One being putting the text effect on the track instead of on a clip. This would make the text not even be a clip on the timeline and would just sit on top of whatever is in the timeline on that track. This could make the text appear and disappear based on whether there’s media on the track. Literally the only case I can think that would be useful for is lyric videos, but I’m not exactly a content creator beyond just little edits for songs so I’m pretty narrow in scope here. Kind of a neat idea to play with using the dynamic text effect.
Also, I found there is a (likely long-depreciated) clip type that doesn’t normally show in kdenlive. If you drop in a .txt file into the project bin you get a different sort of text editor. No viewport, no start and end animation to fiddle with, just a straight forward text editor. It’s not fully featured as far as properties go (centering, line spacing, kerning, etc.) , but I do much prefer how it functions over the title clips. Honestly if it had more format options I’d just use that. Oh well.
How would that be any different to just placing a “text clip” on a track above what you want to overlay it on and using the normal compositing with all the functionality it offers to combine them?
Text, like still images and motion picture clips, is ‘content’, and you can use effects to manipulate that content. If you make text an ‘effect’ then it can’t exist without some other ‘canvas’ content to act upon - at which point you’ve just reinvented / deconstructed title clips without fundamentally adding anything that isn’t already possible with them.
Anyway, there’s two questions here:
What concrete things would improve title/text clips.
How can you do what you want with the functionality already in kdenlive today.
If the clip you posted is representative of what you want to do, then there’s several ways you could already do this quite easily.
The simplest, and what I’d probably do for the clip you’ve shown is just split the text over multiple title clips: “Verse 1”, “chorus”, “Verse 2”, etc. instead of trying to force it all into a single Wall of Text that you’re never going to use in that form.
Then you get plenty of reuse points for each bit of work you need to do. You only need to do the chorus once and can drop it each place it occurs. And if the verses are regularly formed and the band is tight, you can probably make one set of effect keyframes and reuse them for each verse too.
If you wanted to do something more fancy with what scrolls by, it is in fact possible to modify the viewport animation to be non-linear. You can’t at present apply time remapping directly to a title clip (though that seems like a separate (currently a crasher) bug which should be fixed at some point) - but you can drop the title clip(s) into a separate sequence and then time remap that animation in your main timeline.
That’s a bit more fiddly than just moving the text around with a transform, but it does let you take the default scrolling animation and speed it up, slow it down, pause it, reverse it, or jump to any point in it that you like.
Do you have a case where that still doesn’t work to do what you need today (even if there may be even better ways to do it in the future)?
I appreciate the continued discussion on this. There’s a fair bit to address in your response, so I apologize for the lengthy reply.
So, placing text as an effect on the surface does look exactly the same as if you just used a bunch of title clips. However, since effects don’t create clips in the project bin which are edited in a seperate window, editing and keyframing would move to the effect tab. This would make a more simplified workflow regardless of the amount of text we’re talking about. If I have to double click the clip in the timeline or project bin to open the clip in another window just to change something about the format of the text then that is extra steps as opposed to just making an update in the effect tab. Any workflow and editing related tasks would be moved out of that separated window and positioned next to the timeline where edits can be done more seamlessly. The person looking at the finished product might not know a difference, but the person making the video would.
The way text is loaded in from the title clip editor assumes you don’t need anything outside of the view port. A toggle or default functionality to show the overflow would be an improvement. Also, as previously mentioned, being able to edit the text without having to open a separate window would greatly improve workflow. As far as I’m aware, and as best as I’ve looked, there is no way to dock the title clip editor. Correct me if I’m wrong on that.
I can’t without compromising workflow or quality. I have to make many title clips, distort a single title clip with manipulated viewport sizes, or import a PNG created from a software outside of kdenlive. Not to be dismissive, but technically I can’t achieve in kdenlive what I can in other editors without making compromises.
Yes, but there is additional work that would go into making it in that way which isn’t an issue in other editors. There’s also issues of length for song sections that would make it not all fit in the way you’ve described. I can’t often make just a “verse 1” title clip because the verse is too long and would need a “verse 1-1” and “verse 1-2” - which wouldn’t be needed if the title clip showed the overflow which just brings us back to my past points.
Kdenlive has the far superior ux in pretty much every way except for this one thing that might be niche but dictates my entire workflow. If I have to choose between making things easily in an editor I overall enjoy less or making things more difficultly in an editor I overall like more, I’m going to choose the easy route every time. And animating one text clip is easier than animating ten. Changing properties on one text clip is easier than ten. Managing keyframes is easier on one than ten. If I need to change overall font sizes, colors, font family, or any display property I’ll need to do this across all the title clips if I split it up that way. It’s just a far more frustrating workflow than having one singular clip.
Not trying to sound sarcastic or crass, but this is my entire reason for creating this post. It’s so much to fiddle with. Everything in kdenlive is so easy to pick up that running into the only thing that I have to actively fight with - and that one thing being the basis for my entire workflow - to do what I want is really unfortunate. Yes there are ways to work around this issue, . But would you be contented with workarounds as an end user or would you just look for other options? I think most people would rather look for other options, but that doesn’t mean I want to - which is why I made this post. I want to use kdenlive because of how much I genuinely prefer it. I just don’t want the extra work I’d have to do in order to make that happen. It simply wouldn’t be worth the fiddling.
I don’t think I can answer this without repeating my other points in this reply but I did want to acknowledge the question.
The title editor was some sort of a bolt-on that hasn’t received enough TLC since its inception. An attempt for improving it was made during one of the Google Summer-of-Code events a while ago but sadly didn’t lead anywhere.
I certainly hope that changing the way Kdenlive handles clips with different dimensions than the project opens new possibilities for title clips. Nevertheless, I strongly encourage you to open a bug report and submit your case as a feature request (aka wishlist item). Perhaps there is an easy enough solution already available, but at any rate this is the best way to get the dev’s attention.
I got that impression from the title clip editor. It felt like it was designed after an old version of the Vegas Pro title editor - which I also greatly disliked. Ironically, I liked almost every aspect of Vegas Pro, and a lot of kdenlive reminds me of the parts of VP that I did like but kdenlive greatly improved upon those things in amazing ways. That being said, one of the reasons I quit using VP (but not the only reason) was because of the title editor.
Thanks for the recommendation. Just submitted the wishlist request. Here’s hoping something comes of it in the future!
Sorry, I’ll take some blame for this … after my repeated quizzing for an explanation of exactly what you wanted to do instead of descriptions about how you’d been trying to do it unsuccessfully, perhaps it wasn’t clear that this:
Was a rhetorical device to frame the rest of my answer, not a sign that I’d forgotten what had already been said and needed to recap that.
So let me perhaps rephrase and clarify that a bit.
In the words of those so famous lyrics: yes, there are two paths you can go by …
you can dream about all the things that kdenlive could change which would make doing this in the way that you’ve already imagined doing it suck less in some indeterminately distant future.
or you can get on with actually doing them today by learning a different way to do it that takes full advantage of what kdenlive can do and does do well, instead of thinking that you can somehow find a loophole to make your old way work through sheer force of will.
And I don’t want to discourage anyone from thinking about how things could be done better - but the simple reality on the ground here is, if you had some small suggestion of some small thing that could be changed that would make a big usability difference for a lot of users, or some bug that prevented something that should work from actually doing so - then there is some small chance of that maybe getting changed or fixed sometime in the next few months or years.
But if you want to totally reimagine the fundamental operation … then unless you’re submitting proof of concept patches (and even then), I wouldn’t suggest holding your breath while you wait.
So … in the long run, there’s still (plenty of) time to change the road you’re on …
And how you can do this quite efficiently and fairly painlessly today are the practical answers that Bernd and I have been trying to give you.
I don’t want to just hand wave away the thoughts you’ve had on improving this though, so let’s cue up Imagine for background music and look closer at a few of the details there too …
[quotes trimmed just to indicate which part of what you said I’m referring to, not to in any way change what you actually said in each case]
You might think that’s “simpler” if what you are doing means the body of the text is just something that you copypaste in as a blob and don’t otherwise care much about - but I would find it horrific to have to compose and edit a substantial body of original text in a tiny text widget in the effect tab. It’s already bad enough in the title dialog - but trying to manage a 4k or larger frame of arbitrarily positioned and sized text in a thumbnail size box in the effects tab would be a complete non-starter.
I don’t think that conflating the editing of the ‘content’ (the text and its fundamental properties), and the keyframing of its animated manipulations (the effects later applied to that content) is a good way to frame this for general purpose use. They are separate jobs best kept separate. I should be able to use any effect on the content of a text clip, not just the ones made part of a ‘text effect’, and should be able to composite it with any other content clip like the content that it is.
It doesn’t assume that at all. It gives you a project frame sized area to lay out whatever text you wish, and doesn’t limit you to only the amount of text that can fit in a single unit of that area.
The functionality it provides to animate text entering and leaving the display frame is fairly rudimentary, but it inherently assumes that you do want to pass a larger body of text from a single clip through the viewport.
Until MLT allows working with a ‘virtual’ clip space that is larger than the project frame viewport this is the consistent behaviour of transforms for all clip types, not some special limitation of a text clip.
It’s your assumption that things outside that space remain accessible which is conflicting with the current reality in this case, not some special limitation of the title editor which would magically go away if it was made an effect or implemented differently. Fixing that requires fundamental changes to how all clips are handled (which are already on the long term roadmap).
This was the rhetorical question that Bernd and I have been trying to answer for you - not a question that I was expecting you to answer
Your attempts to do it in ways that fundamentally weren’t ever going to work well made that “the question you actually wanted answered” if you were going to do this with any currently, or soon to be, released version of kdenlive - and it really is very possible and fairly easy to do what’s in the example that you showed in kdenlive today - without compromise on the amount of effort required (other than the initial investment in learning new skills) or resulting quality.
If you want to insist that “the way I did this with other tools is the best and only way to do this” - then sure, you are going to die on that hill. I can’t argue with that. It’s like me complaining that my screwdriver just does not put screws in the same way that I can put them in with my hammer.
There are pros and cons to both of those systems - you just haven’t experimented with how the screwdriver works yet to see what you gain in exchange for what you have to do differently to what you’ve done in the past.
There is different work to do it this way. That does not automatically imply there is significantly more work, and gives no credit to the substantial amounts of duplicate work that it can save you if done right.
I know change can be painful - but clearly there’s some very good reasons why you’ve changed from using the tools that you learned this workflow in - so maybe there’s some value in exploring what works best for this in the new tool too.
Suggestions to improve it might themselves be greatly improved with a fuller appreciation of what can work in your favour rather than just what doesn’t work if you just try to do what you learned with a different tool.
Trying to eat with chopsticks the way you’d eat with a knife and fork (or vice versa) is not going to give you the best experience of them. That doesn’t make either set of tools inherently inferior or unfit for purpose.
Splitting along those arbitrary boundaries I gave was just one example - for instance in the example you showed, I’d actually split a lot of that at the level of single lines, and group some of the commonly repeated combinations.
That would greatly reduce the amount of repeated and duplicated work needed to animate and align that text to the audio.
Not when you can do it by creating two small animations and then pasting them 8 times instead of painstakingly duplicating all of that manually over the whole body of a single, large, in many ways repetitive, wall of text.
If I need to change which rooms of my house are bathrooms and which are bedrooms, that’s going to be a fairly major operation too. Some things you do have to decide or experiment with at the design stage of work rather than thrash with trying to change them after the work is completed …
If you’re not doing that, then you’re going to spend a lot of time doing frustrated rework whatever workflow you use.
Which I do find kind of meta-amusing, because it is the only part of what I wrote there which returned to asking you an actual question rather than trying to explain a workflow that through long experience (and not withstanding the other well known little niggles with the title tool) actually works quite well - and especially so in cases where the same or very similar text is reused multiple times in the same or derived projects.
I’m not trying to dismiss you arguing your preferences - or saying the text tool in shotcut that you showed had no redeeming benefits - but I think at this point ‘the argument’ would probably get a whole lot more constructive if you actually tried the things that we’re suggesting would work better than what you’ve so far attempted in kdenlive - and then talked about the real experience of what was actually better and worse once you’ve developed some new skills and expertise in working that way - rather than just imagining all the things that might be horrible about using a different tool differently.
Imma be real with you chief, I’m not reading that. Idk how you could have that much to say but it ain’t worth it. It’s just an effect request. It ain’t that serious. Cheers.
meh, it’s your head, I don’t care what wall you want to smack it against.
My interest was finding out if you actually had some use case that kdenlive struggled with. You don’t. If you’d rather do simple things the hard way then it’s your life to waste.
