Removing transition (with restoring previous clips)

[TimLau]

Even if you store the state of and transition, it can give problems for all the actions you made after creating a transition, they was all build on how the world looked after you made a transition, so this is here the time travel analogy comes in.

[ken_wawa]

It’s mostly the question of “space” after two clips (+transition). However here I believe it can be easily solved either with overwriting either with rippling (depending on the switches…) like with many other things. And for sure it can make some mess after clips but I believe it’s exactly the same story like… making unintentionally transitions.

[gseydack]

As an occasional Shotcut user, making only the occasional holiday movie, I read this thread with interest as it deals with the normal kind of stuff that I as a newbie might also encounter. I must admit that I’m left puzzled about something that seems elementary to me. Let me assume that I were to create a transition between two clips, and some time afterwards want to make changes, regardless of whether to fix a mistake or a change of mind. What is there to stop me from simply removing the two clips, replacing them with the originals, and fixing up the result to look and sound the way I really want it? As an aside, the discussion seems to have focused on images and largely ignored the effect on audio, and it might be much more difficult to make the resulting video sound right than to make it look right. After all, I still have the original clips, as Shotcut only creates an editing template according to which it creates the final output. It doesn’t change the original clips, unless one does something incredibly stupid, no?

[Elusien]

You can do this, but if you have applied several filters to the original clips then delete the clips and replace them with the originals you will lose all those filters and have to apply them all over again.

EDIT: You may also have removed parts of the clips from the front and/or back. You would need to do this again too. It is possible to move the clips to another track, put the origials back where they were, edit them then copy filters across from the ones moved to the other track then delete these. But surely this is a lot more hassle?

[gseydack]

Thanks, Elusien, I agree that things might become a hassle; indeed, this is one of my takeaways from this discussion, considering all the ideas voiced here. The methods that you and TimLau showed seem very useful to me, and I’ll keep them in mind should I experience this problem at some time.

[Elusien]

See below for a video tutorial I made for undoing a transition created by dragging one clip over another:

Tutorial on How to Undo a Transition Created by Dragging One Clip Over Another

I have placed a video tutorial on my YouTube channel: https://www.youtube.com/channel/UCQOLZvd3sbB_N2yM_PJh0qA that describes the procedure for undoing a transition that was made by dragging one clip over another. There are other ways of producing a transition but this tutorial will only work for ones made specifically this way. I am currently producing a second tutorial video to describe how to undo a transition made by extending one clip over another. Care must be taken if there are any other…

[gseydack]

Great, thanks! This makes it quite clear even for a ‘not-so-regular’ like me

[ken_wawa]

Hi,

I was thinking a bit about this transition desplit problem. What about the following idea and algorithm (sure it’s on very general level)

When transition is created the following object is created:

    Transition T 
    {
    clip A with startA, endA, all filters
    clip B with startB, endB, all filters
    startTransition
    endTransition
    typeTransition
}

when start, end are time markers, and they are including transition (so endA>startB)

Next when we want to de-split transition we use the following algorithm.

1. For clip A, we restore it at position startA, endA with all filters (that’s simple)
2. For clip B (and here it’s more tricky):
   2a. we check if ripple is on (for given or all tracks), if yes we do ripple and move all objects after endA by time (endTransition-startTransition) (according to rippling rules) and next we put clip B with all filters at position newStartB = endA +1 and newEndB = newStartB + (endB-startB (the values kept in transition object)); end of procedure
   2b. if ripple if off (and here I have the most doubts) I can see few options

first proposal the simplest:
we calculate newStartB and newEndB like in point 2a and next we check if between newStartB and newEndB points there are any objects on track, if yes we undo transaction and display the message “de-split is not possible, you need more space on track to de-split” (user could do more space on track manually, but still it might be better than working manually according to the algorithm from video), if no objects, then we simply put clip B at newStartB, newEndB positions with all filters

second option
we calculate newStartB and newEndB like in point 2a and next we check if between newStartB and newEndB points there are any objects on the track
if no, then we just put clip B with newStartB and newEndB
if yes, then we take start for the first object being on the track, and we set end of clip B as newEndB=this object start point -1 (thus in consequence clip B would be shortened)

third option
would be the most complicated and i would not go into this direction as it would make algorithm quite complicated to be written but also it would be a bit unpredictable from end user perspective so that’s why I mention it only in very simple way - we could analyse all objects being on the track between new

Personally I would select the first option. Firstly because in most cases there will be space for putting the whole clip B. Secondly it’s the most predictable for end user and he can easily make space by moving ex. next clip or clips to another track and then once again de-split automatically.

What do you think about it?

[shotcut]

@ken_wawa

For clip A, we restore it at position startA, endA with all filters (that’s simple)

What if there is something else there now? Don’t forget about the case of making a transition by moving the first clip rightward over the second clip.

undo transaction and display the message “de-split is not possible

nah, just do what it does today.

second option

That seems reasonable to me.

Also, I think the current behavior ((Lift or Ripple Delete) should be retained somehow. I can give up a Lift-and-fill-50/50 operation if I still have plain old Lift because, again, many edits should be reconsidered after removal of a transition. New behavior can be in a separate Remove Transition action.

[brian]

@shotcut

New behavior can be in a separate Remove Transition action.

There could be multiple remove transition actions in a right-click context menu:

• Remove and extend left clip
• Remove and extend right clip
• Remove and extend both clips half way
• Remove and shift clips right (ripple)
• Remove and shift clips left (ripple)
• Remove and do not extend anything

Just throwing it out there - I do not volunteer to write all those actions

[ken_wawa]

@shotcut

What if there is something else there now? Don’t forget about the case of making a transition by moving the first clip rightward over the second clip.

Point for you! But here it could finish with displaying the same message “de-split” is not possible.

As we can write many different scenarios (subcases), I believe that this algorithm should be simplified. Otherwise we risk that 1) noone would like to write it in code 2) there will be many errors causing crashes and then in practice it will not be helpful/useful 3) users will not be able to understand how it works and then they will be surprised (quite often not nicely) with the result having impression that it works wrong (just because the rules would be too complicated).

To my humble opinion, it should be done in the way that it should cover only part of cases and for the rest, automatic de-split should not be possible (or left for later for someone who will be ready to write all those cases in algorithm). However if automatic de-split would be possible even in 80% of cases, that would be very helpful for me and I believe for many other users. Moreover you would keep detailed data in mlt file about transitions (probably more than now but I might be wrong here) so it would keep the way open for future for making something more sophisticated.

@shotcut

Also, I think the current behavior ((Lift or Ripple Delete) should be retained somehow. I can give up a Lift-and-fill-50/50 operation if I still have plain old Lift because, again, many edits should be reconsidered after removal of a transition. New behavior can be in a separate Remove Transition action.

Here I feel a bit lost (either perhaps because I’m not good enough in shotcut, either because English is not my native language, either both )

[candarzop]

I think any change you make that says “Undo a Transition” should restore the two clips to their original length before the transition was made, which is what I suspect the majority users would want.