I’m new to the community, so forgive me if this question has been already addressed.
Differently from most of the other editing application, I’ve noticed that once a transition is applied overlapping two adjacent clips, the result cannot be easily edited if not undoing the action and repeating the overlap, which moreover can be created only by approximatively sliding the clip over the other using the mouse. More specifically what I’d like to do is to be able to enter explicitly a number identifying the number of seconds and frames the transition should last and once the transition is created to be able to change the duration entering a new time.
Is there a way to do this in the current version or if not, is there any plan to add this feature?
It’s not approximation. Every time you are moving clips there is a dialog box that appears showing you in frames, second and minutes how much movement you’ve made with the clip you are dragging since you started to drag it. That includes when you are making transitions and stretching in or out the ends of the transition clip…
Also, the playhead can be placed at the end point in advance. Then, when the first clip is moved to overlap the second clip, it will snap to the playhead if magnetic mode is turned on.
Thank you for the swift reply.
Well yes I understand you have a precise feedback of your movement but still the transition timing is to be set by hand. It would be good to have the ability to enter a number.
Thanks, that’s is a good hint. I didn’t think about it.
Still, out of curiosity, not sure to understand why hard cutting the transition into the clip instead of creating an overlay that could be edited on its own. (as in the majority of editing software by the way).
I also found this to be a bit unwieldy, to the point that years ago I stopped doing drag-over transitions altogether. If I need a crossfade, I InsertTrack and put the second clip above or below.
This gives me the added advantage of being able to lock-out one of the two tracks to remain unchanged while using RippleClips and RippleTracks to overlay the clips in time.
That is only the basic way of creating a transition, which is still easily controllable. There are other methods of creating transitions that do not use this method and are as easily controllable. Do a search on YouTube for Shotcut Transitions or you may find methods in this playlist that includes adding layers that you would consider “non destructive”: https://youtube.com/playlist?list=PLpO3ttBDkV5uFHUIfsYL9IIk30TeQqCsj
only by approximatively sliding the clip over the other
are incorrect. Transitions can also be created and edited by trimming. True, there is no way to enter and edit a transition numerically unless you edit the project XML file.
well, I disagree but it is far from me the idea of starting a fight regarding how easy it is to create and edit a Cross-Fade with ShotCut. The application is great and it is even free, so this it’s more than enough.
My intent was to check if I was missing anything in doing a Cross-Fade since I thought it was quite peculiar the way it was implemented, at least unique in the editing applications panorama.
I’m still convinced that creating a clip containing the just transition is conceptually wrong and counterintuitive as well as more difficult to correct than if the Cross-Fade was treated as a Filter. Moreover, this is to me still less understandable if you consider that the FADE-IN and FADE-OUT features are already implemented as Filters. In fact, I believe many users, including myself, are using the FADE-IN and FADE-OUT filters between two video tracks to create a cross-fade, as is mentioned also in this thread.
It is conceptually different. Since it does work, I’m hesitant to call it wrong.
I almost always use two separate tracks with fades like you do for many of the same reasons you mentioned. However, I do occasionally revert to the single-track dedicated transition because its real power surfaces for effects other than dissolves. Things like wipes, masked transitions, etc that could technically be done with two tracks using the “Mask: From File” filter, but not without having to retime the video mask if the transition needs to be a different length. For some of these tasks, the dedicated transition is indeed easier to set up and retime.
It’s all about having multiple tools that specialize at different jobs.
Keyframes had not been added to Shotcut back when this was first implemented, I believe.
Now it would be easy for the software to automatically retime the hidden Keyframes of a transition done out-of-sight using filters.
It could be done, now, that was then.
But if Shotcut ever has a from-the-foundations-up revision…
Keyframes are not necessary for either of the scenarios I was referring to.
Two-track fade-in/fade-out can be done with the traditional fade filters which have a duration as a parameter. Keyframes aren’t needed.
As for retiming the video mask, I perhaps used a confusing term. Consider @jonray’s 161 video transitions. Let’s say one of those files is 2 seconds long. If I want to shorten it to a 1 second transition, then I have to change the Speed property of the transition video to 2x and then realign the clips around it to this new duration. None of that involves keyframes. For simple masks, this is potentially more complicated than using a PNG mask on a single-track dedicated transition clip.
I was saying that they are a possible behind-the-curtain mechanism developers could use.
Today.
One of many possible choices of mechanism.
That this mechanism was not available when the choice was made to make the transition a separate clip, a choice that was the correct one at that time, and is too entrenched now to be easily changed.
If I remember the history correctly, the overlapping-clips-makes-a-transition mechanism was made that way because Dan preferred it to two-track fades for his own editing. Technical issues had little if anything to do with it. As such, “entrenched” is desirable behavior rather than a legacy issue. My apologies Dan if I have remembered the story wrong.
It was also a means to enable “advanced transitions” like wipes and masks before “Mask: From File” came into existence, which kinda fits your theory. The dedicated transition clip is still preferable in some instances because it’s easier to change the length of a transition clip than it is the length of a mask video and everything else linked to it.
I was speaking of how such a overlapping tracks fade would be done behind the curtain, once the decision had been made to implement it, not referring to the decision to make the UI “just drag the clips together”.
When I said “retime”, I was referring to the duration of the transition. This isn’t changed by filters or keyframes.
It seems that you’re referring to changing the intensity levels of background keyframes to control the look of the transition itself over the fixed duration of the clip.
I meant retime as in duration, then realignment of clips that are synced to it. I think you saw retime as in parameters/keyframes of the transition itself.
“Retime” was a poor choice of words. Sorry for the confusion.
Actually, I have been looking at this from the perspective of the software engineer who must implement the decisions of the leaders.
Imagine if, years ago, Brian had come into my cubicle and said “Dan has decided that dragging two clips over each other will cause a transition. Make it happen in time for the next scheduled release.”
So I say to myself “But what if the user later moves the clip, changing the length of the transition?”
Hmmm…
Clips have length…
It I make the transition a clip of its own, I only need to adjust… …and I can use this and this existing software.
On the other hand, what if Shotcut still, today, did not have this feature (drag over transition), and as a software engineer I was given the same instruction?
I would say to myself, “We have Masks and Keyframes. What If I create a hidden Mask, Keyframe it, and then if the user changes the length of the overlap, my software will simply recalculate the length and slope of the Keyframes, behind the curtain invisibly.”
It is about implementation details and feasibility, not about UI decisions.