Removing transition (with restoring previous clips)

I’m not asking for free stuff. I am quite happy to undo transitions as I always have, using the method I outlined above. It isn’t something I do very often.

I am merely stating that if you do produce an “Undo Transition” function that doesn’t return the clips back to the state they were in before you did the transition then users will be confused and claim it’s a bug, rather than a feature. Having done a search I can see that most posts on this forum that say they would like a way of undoing a transition state that they would like the clips to return to their original length.

2 Likes

How does it work in other video editors?

If you by right mean, that the clips are exactly before the transition was made, the problem here that you if you extend both clips, then you ripple the timeline and potential mess up the timing with other tracks made after the transaction. So my method is more like removing a transaction in a way that don’t mess up the timing of the timeline.
A real undo can only be performed “correctly” by undoing the all actions done until before the transition was made in the first place and you will loose all changes made after.
Another problem is that, if the transaction is made by a mistake and you first find out much later, you need to know how the transaction was made to be able to resize the clips to the size before the transaction, there is 4 ways and that information don’t exist in the transition itself.

2 Likes

Thanks for showing the various options of how to make the transitions.

I’ve always used the “drag one clip over the other”, not the “extend one clip over the other”, since the transition is usually needed at the absolute end of one clip and the absolute beginning of another and you cannot extend these. Also, doing a transition by the “extend one clip over the other” method restores the part that I deliberately deleted, so why would I do that? It’s an option that others might use, but I doubt if I ever would.

So the answer to the OP’s question

is basically, “Possibly, if you know how you did the transition and know what you are doing”.

  1. If you did it by extending one of the clips, you delete the transition and extend the clip you didn’t extend last time, making sure you do not have “Ripple” on.
  2. If you did it by dragging one clip over another you turn “Ripple” (and probably “Ripple All Tracks”) on and extend both clips according to the method I showed.

In 1) you shouldn’t need to worry too much as you will not affect other clips, nor their synchronicity. In 2) you should be very careful as clips will move and synchronicity between tracks may be affected.

2 Likes

Thanks for all those explanations. It would be still nice to have some function automatically removing transitions. But it’s probably much easier to say than to do… :stuck_out_tongue:

What is what my example shows, that are 4 cases and no information about witch one was used, to for an automatic removal you must select one action for what to do with the space under the transition.
It’s a little like a time travel paradox, where you go back in time and change something and when you go back to now, then it might have changed things to something you don’t expected.

1 Like

I wouldn’t go so deeply… Simply for me transition object should keep state (=have additional properties/data stored in the moment when transition is created) which should allow to make de-split automatically. I’m not saying it’s easy but for sure it doesn’t require travelling in time… :stuck_out_tongue:

1 Like

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. :scream:

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.

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?

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?

2 Likes

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.

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

1 Like

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

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?

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.

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

Point for you! :slight_smile: 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.

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 :stuck_out_tongue: )

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.

This topic was automatically closed after 90 days. New replies are no longer allowed.