Ripple Logic Failure when Changing Speed of Sandwiched Clips

Hi there, thanks for your attention! I’ve encountered an issue where the timeline logic breaks during speed adjustments. Here are the details:

1. System Information:

  • Shotcut Version: 26.2.26

  • Operating System: Windows 11 Pro

2. Description of the Issue: I am experiencing a severe timeline management bug when decreasing the speed of a clip (making it longer) that is positioned between other segments.

Crucially, even with “Ripple” (and “Ripple All Tracks”) enabled, the software fails to shift the subsequent clips to the right. Instead of moving the timeline to accommodate the new length, the modified clip either:

  1. Stops expanding when it hits the next clip (Collision).

  2. Or overlaps/overwrites the beginning of the next clip.

I noticed similar reports online (e.g., in v24.01.28) suggesting this often happens when there is a gap between the modified clip and the next one. In my case, the bug is most reproducible when the middle clip is short and the surrounding clips are long.

3. Steps to Reproduce:

  1. Enable Ripple (and Ripple All Tracks).

  2. Place three clips back-to-back (or with a small gap) on the V1 track.

  3. Select the middle clip.

  4. In Properties, change the speed to 0.5x (slowing it down).

  5. Observe that the clips to the right are NOT pushed back as expected.

4. Expected Result: The timeline should automatically ripple all downstream clips to the right to make room for the expanded slow-motion clip.

5. Actual Result: The Ripple function fails. The clips collide or overlap, and the relative positions of the rest of the project are messed up

I have not reproduced it.

It’s working as expected for me too.

2 Likes

Thanks for the help testing

Hi, thank you for your attention!

Regarding the Ripple issue, I must clarify that it is an intermittent bug. I just spent some time trying to find a consistent reproduction path, but I haven’t been able to trigger it again successfully yet. I will keep a close eye on it and provide a screen recording and application logs immediately if it happens again.

In the meantime, I have posted another bug report regarding the first and last frames of a clip not stretching correctly after a speed change. That issue seems much more consistent and easier to reproduce. I would appreciate it if you could take a look at that one as well. Thanks!