Preserve the speed control strip in Blender 5

Summary

The idea to not remove the existing Speed effect strip (and possible Hold offset) VSE features in the upcoming Blender 5.0. The Speed effect strip is most important to save, because loosing the ability of using F-Curves and modifiers to manipulate timings of a strip would be very unfortunate in my opinion.

Background

The developers are putting in the queue the following Breaking VFX & Video changes for 5.0:

   1) Remove Speed effect strip in favor of retiming system;
   2) Remove “hold offset” properties in favor of retiming freeze frame;
   3) Remove Transform effect strip.

Review

Speed effect strip.

I do not think that the retiming system should be considered as a replacement for the speed effect strip, considering the limited functionality of the first. It does not use the consistent Blender keyframes and do not support Graph editor F-Curves and modifiers, so some task like stepped interpolation for stop-motion effect, loop repeat, ping-pong effect or smooth transition from stop-frame are either not possible or clumsy. The speed effect strip does not have limitation apllying to other effect strips.

Retiming keys quickly become stuck and getting in the way of each other, so they suits for quick and simple re-timings. Besides they are not quite there yet, for example, retiming system has trouble with nested scene strips in meta-strips. On the other hand the speed effect strip is good for advanced re-timing with the fine control, and can use advantage of modifiers. That makes it not only to surpass the retiming keyframes capabilities, but also many other video editing software. Also speed effect strip better handle the video files with compromised timings (such as video recording with unexpected end). So it is more stable and consistent in general. I’m heavily using both speed effect strip and retimng, so that comes from a personal experience.

Hold offset.

Though not as important as the speed effect strip, this feature also very convenient and simple to use. Lets compare a behavior of the freeze frame and the hard cut (which currently using hold offset) features on an example. The goal is to cut strip and have two resulting strips with a frozen frame at cut point and have a gap between these strips. With the current hold split strips:

   1) make a hard split,
   2) slide the already selected strip or select the other strip and slide the strip.

The result as described above with an infinite frozen frame in the direction of the cut and the original speed. It is now possible to select one of the strips and tweak handle of the other, and slide them together maintaining the gap.

With the current hold split strips:

   1) insert a freeze frame,
   2) confirm or cancel the pending action (so the timing of the strip wouldn’t change),
   3) select the strip (because now the retiming context is activated),
   4) make a split,
   5) slide the already selected strip or select the other strip and slide the strip.

Even if the steps 1-4 would be implemented in the hard split action, the result below may be similar. The result are two strips with the almost original speed (with some minor changes on the right strip) and a frozen frame of one frame length in the direction of the cut. To move the frozen frame of the right strip to the left (in the direction of the cut), there is needed a good aim or zoom in to select the left keyftame and move it left, alternatively slide the tweak handle first, then the keyframe. It is impossible to move frozen frame and the other strip simultaneously because they are in the separate contexts. However, it is possible to select all the frames in the other strip and slide them simultaneously, but it is not convenient if there is many keyframes or they offset out of the view. Also it is not consisted directionally (slide left is different to slide right). To move the frozen frame of the left strip to the right (in the direction of the cut), first necessary to slide the right handle, then select and slide the frozen keyframe, align it with the extreme keyframe then continue sliding.

Alternatively, the operation could be done with the different order (e.g. separate the strip and then hold the frame for the each resulting strip separately), but ultimately the setup is more complicated than with the hold offset. Also it is generally troublesome to add the freeze time while maintaining the strip speed. Of course the retiming system may be improved yet, but the design itself is too different and handles well others, but not this particular task. It is just “easy to use” differences and not have such an impact as speed effect strip.

Transform effect strip

No arguments here, the effect is deprecated and superseded by Transform properties. Although there is may be some use cases for this strip, such as using it as an adjustment layer for a singular strip or creating a linked “clones” of the original strip, it is not worth maintaining and superseded by other features.

Conclusion

The removal of the Speed effect strip would be a huge step back, in my opinion. Mainly because of discarding the Length and the Frame Number Speed control methods. Although the retiming system capable to deliver faster and easier results for simple re-timing tasks, it lacks the necessary flexibility for advanced tasks.

The removal of the “hold offset” properties with the current state of the retiming system would introduce more complicated setups for such simple task as “cut and hold” and can provide some disadvantages for other time related features (such as the speed control or the retiming system), but the core functionality will preserve for most of the cases.