Previously (pre-2.70) scaling a keyframe with automatic handle type set the handles to aligned type, and now it doesn't. Scaling automatic handles does nothing, while when the transform changed the handle type scaling individual keyframes to change handle length was possible. This seems like a regression, although might be desired in some cases.

This is from my own commit, rB6cc5bdc99e63b05248f132833bfe0259c2a27923

The problem I found is - if you wanted to increase the amplitude of a curve, or make it take longer/shorter.
Auto handles would always be removed, and in many cases this isn't needed to change the overall scale of a curve.

You don't have to move every keyframe manually - you just have to set the handle type if you don't want it to be auto,
which you can do before transforming.

Setting handle types to aligned can be done by pressing V, A

Can you upload Blend where you would want handles to scale too? (maybe this can be detected somehow).

@Joshua Leung (aligorith)
What are you thoughts on this? - it seems like there should be ways to do both actions.

Brainstorming.

• Add a way to scale curve handles - since in this case this is the goal anyway, if its explicit you want to scale the handles rather then the distance between them, changing the handle types makes sense in that case (Alt+S could be used for eg).
• Make it an option (I'd rather not)
• Use the 'Show Handles' (This is using a view option to effect how transform works, so Id rather not do that too)
• Treat single handles differently (doesn't actually address this report)
• Detect these cases: Do a min-max on the transform data, If you scale on an axis which has 0.0 size, change handle types. (seems overkill and a bit hidden)
• Add an option in the Handle Types menu to disable auto (so non auto handles are left alone).

If this commit is too disruptive and needs to be reverted, there really should be a way to scale without changing handle types IMHO, even if its accessed via some option, key-binding.

◀ Merged tasks: T39316.

I'm still not convinced about the case for why that offending commit is needed. TBH, I'd been planning on just reverting that commit - it's just that I haven't gotten around to that on my todo list this week yet!

What is clear though is that it is quite clunky to have to remember to change handle types first.

If we do eventually agree that it is really necessary to do both, I propose that we restrict the handle type changing to "individual pivots" mode (yes we have such a thing in the graph editor, like in 3d view).

Alternatively/additionally, we should ensure that it is ALWAYS possible to manipulate the handles at will if there's only a single keyframe selected. Again, any nominal consistency with 3d view behaviour is here is IMO ill founded and unnecessary

having a special case for scaling single keyframes, works nicely for scaling on the X axis, but scaling Y axis it would change handles unnecessarily.

Was thinking perhaps it could work like this:

• Transform changes handles (as before)
• After transformation executes, detect if any handles that started as auto-handles would remain the same if kept as auto handles
• Set auto handles for these.

While this seems a bit over complicated, I think its not actually that big of a deal to do, and it means auto-handles can be kept in many cases.

I think the value of preserving handle types is higher than the value of not having to change te handle type before applying this kind of specific 1 frame scale. It will of course raise some bug reports since it's a change in behavior but I like it. It preserves valuable user choices instead of trowing them away without notice.

If we can't find a good solution, it may be best to revert my commit for 2.70a and investigate changes for 2.71.

Added this to 2.70 project.

+1 - I think it's best we revert for 2.70a and then work out a better long term solution