What is your Shotcut version (see Help > About Shotcut)?
24.01.28
Can you repeat the problem? If so, what are the steps?
Changing the speed of a subclip IF there’s no other clip immediately after it on he same track (but there are clips on all tracks further in the project) messes up the relative positions of the clips.
Ripple + Ripple all tracks enabled. Undo doesn’t properly revert it.
Everything works correctly if there’s a clip immediately following the clip to be sped up/down. My workaround is to split the last frame of the clip so there’s something behind.
I can make a sample project with colored clips if needed but I think it’s easy to replicate, just make sure there’s clips on all affected tracks further in the timeline.
I think it is doing what it is designed to do, but maybe not what you expect. Here is my attempt to recreate:
Maybe you are not expecting the first clip on the top track to be split. But that is how it is designed - Shotcut fills the available space and then moves everything down after that.
Also, in my video, I performed and “undo” and everything went back to the way it was.
You can’t do that because you can not change the speed of color clips. But if you make a project that only uses one source file, I can replace it with my own source file.
Yes, this is very unexpected for me when ripple is enabled.
But this is not what’s happening. I think I get the intention but it doesn’t logically make sense to consider the blank space part of the current clip. Maybe if it first filled in, then applied the movement [minus the filled space] so as to not overwrite the next clip it would make sense, but that’s not happening and it is never expected (ripple always pushes blank space when doing any other action - like copy-paste).
Actually this made me realise the weird stuff that happened in my screenshot above: the ripple action is applied to the next clip after the blank space so:
in the 0.5x example - as the clip has to double its length, it [correctly] needs to push everything to the right by exactly 1x its original length (see thick horizontal purple bar in my screenshot), and it does exactly this… but at the wrong place due to [I think] the blank space behaviour you mention. So instead of adding this 1x length right at its original end, it considers the end of the next clip
in the 2x example again, it needs to delete 1/2 of original clip’s length (thin purple bar), so again it does this but at the wrong location: next clip’s end, but it also doesn’t “delete it”, it inserts the next clip there, and due to this, the original clip that was there is split (just like manually inserting it there would do).
I think this blank space logic is not needed at all, all actions need to start immediately at the end of the current clip whether there’s blank area following or not.
I’ve edited my previous image (sorry for hand drawn lines) to make it more clearly, the vertical dotted line is where the actions are currently happening, the red dotted line is where they should happen (yes, I should have swapped the colors). If the actions happened at the red dotted line it would be perfect.
Without getting into the details of this report, I have been thinking about something related for a long time. A fundamental problem is that Ripple All Tracks is too difficult to anticipate for all scenarios. It is programmed with a certain set of rules based on a limited set of unidentified use cases. That does not always hold up to expectations, and it does not scale to the large number of actual use cases. This is the reason why Apple made the magnetic timeline. I am not keen to incrementally add more complexity to satisfy expectations for more use cases over time. Also, keep in mind that some people have learned how to live with current behaviors, and a change will be reported as a bug.
In this particular case I reported I strongly believe this is not the case, if someone figured out the logic of how blank space affects speed + ripple and are using it this way… they are a bit crazy
I fully agree on these counts, and I think fixing the reported bug actually aligns with this philosophy of simplifying the logic behind it. In my mind, the way ripple is intended to work (and most ripple actions already work like this) is quite clear:
if an action would create empty space to the right of the clip (whether it’s delete, trim end or speed up change) the entire timeline (track) is moved to fill that gap -
→ absolutely identical to if ripple wasn’t enabled and I’d manually delete the empty space created by the action
if an action would create “more clip” to the right (so inserting, extending or speed change to slow down the clip), the entire timeline (track) is pushed by that amount to the right starting at the original edge
→ to keep the analogy I created above: absolutely identical to manually moving all content from that point onward with the equivalent length to the right, then doing the action without ripple
mirror these 2 cases for actions affecting the left side (begining) of the clip (so manually extending with the mouse clip to the left and Ripple trim clip in because the “anchor” for these is the begining time of the original clip
The way I described it, adding ripple all tracks into the mix simply makes that same move left or move right action affect all tracks, but always starting from that original point in time that is the end of the current clip (I think of it as the chronological anchor point). This way the only side consequences for other tracks are: for moving left, it will overwrite stuff that existed in the area, and for moving right: it splits and moves the resulting clip to the right → this basically already exists and is working fine for most cases.
I don’t see any exceptions for anything else, all timeline affecting actions could perfectly follow these rules.
I agree with @shotcut’s comments about the complexity of the ripple all tracks behavior and expectations. Even if we find a set of rules that seems more logical, I do not know if we will find a volunteer who is willing to implement it, maintain it, and then deal with all the fallout. I do not volunteer for that.
One thing I notice about ripple all tracks is that trimming the end of a clip seems to be easy to understand. I wonder, for this specific case of speed change if we should change the speed change to be an in-place replacement.
Consider this:
If the user changes the speed of a clip to be faster, the clip will shrink, and the space between the end of the clip and the next clip will increase. Nothing will ripple.
If the user changes the speed of a clip to be slower, the clip will occupy the exact same space as it did before the speed change. Nothing will ripple. After the speed change is applied, the user can trim the out point of the new clip as they see fit. Maybe they will use the ripple features - they can see what is happening as it happens.
If people find this small change agreeable, I am willing to change the speed change feature to be a replace instead of a replace/resize.
That is the current behavior when Ripple is turned off. I am OK to change the behavior to be insensitive to the ripple mode. Then, one can use ripple edit features afterwards to right-size things.
I am confused, I thought we found the root cause of the bug (the blank space after a clip followed by another clip later). Isn’t this something that can be rather easily changed to not consider the blank space?
Can you share the file/snippet location that deals with this? Either I didn’t explain it well enough or I am wildly underestimating the complexity of this action.
Just had a look at the latest nightly and the change is a huge improvement over the previous behaviour. There is more “destruction” on the other tracks but it is very much intuitive and I can easily fill in the area if needed. Thank you.
on the other tracks but it is very much intuitive and I can easily fill in the area if needed. Thank you.