Advanced Keyframe Manipulation Proposal: Smart-Scale

This belongs to a set of three somewhat related proposals that aim to make keyframe manipulation more convenient.

In particular, this proposes a variant of the primitive scale operator to make more sense when working on keyframes:

Smart-Scale

Problem

Scaling keyframes can genuinely be useful while animating. But Blender regular scaling is entirely spatial, it takes no consideration of the temporal nature of keyframes, and produces often frustrating results.

Suppose I have indeed zoomed out and selected an arbitrary range of animation I want to slow down or speed up. Indeed, scaling is the way to go. But as previously mentioned, when working with frames simply changing the current frame, which acts as the pivot for the transformation, and scaling away can cause problems. If I shrink the selection, then empty time is left at (possibly) either side of the segment, and I have to manually fix them all over again (which, thankfully, Push/Pull helps with), and scaling up will cause no end of a mess if the segment overlaps with existing keys.

I can also use Tweak to adjust my timing proportionately, but this requires a meticulous annotation of limited keyframe types and isn't' always applicable. There should be a more applicable solution.

Solution

We can smart scale selected keyframe ranges with Shift+S. When we do so, the entire selection (for strictness, all the frames between the earliest and latest frames selected, including any left unselected) will be scaled from the very earliest (leftmost) frame, and all the successor frames after the latest (rightmost) selected frame will be pushed or pulled, retaining their timing.

...---P--b--b--b--X--b--b----b--X--b---b--b---...

For example, we can Smart-Scale the segment between the two Xes to be shorter, as follows:

...---P--b--b--b--X-b-b--b-X--b---b--b---...

Or slower, like so:

...---P--b--b--b--X---b---b------b---X--b---b--b---...

Details

This will happen regardless of where my current frame cursor is. The pivot is always the earliest selected frame. And there is no empty time or overlaps ever generated. I can now retime my actions as arbitrarily as I want!

We've been assuming all the proposed transformations are being applied along a single channel. But if we select multiple frames on separate channels, the operations would be applied on those different channels without any issues.