Wow! Thanks for the buckloads of caveats that have been exposed. It's good to see that there are still major usability problems with animation before I started spreading a script whose initial scope was way too narrow to provide anything but a neverending stream of "it doesn't work the way I expected".

Those are sincere thanks, indeed. Absolutely no sarcasm implied at all.

The first draft of my script did what I needed it to do, but will obviously require much more thought before it can be presented as anything other than one piece of a complete animation toolkit. I quickly determined that using parameter.ValueFrame() was never going to be useful, as that does not return the actual keyframe values, without any consideration of layers, which I must explore the Python API for details of. Incrementing through all frames in the reversal range, and collecting values using parameter.UnaffectedValue() at least gives me meaningful keyframe values, but still ignores anything to do with layers. So, back to the script editor.

If I'm keyframing sinusoids, I never trust a simple minimum and maximum per cycle, since your frame adjustment shows that a keyframe gives no assurance of any particular phase in such a spline. It always requires the zero crossings (maximum and minimum slope or first derivative) to be keyframed as well. At the start and end of the wave, multiple, adjacent keyframes need to be specified to conform to a sinusoid, too.

---

My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.