This is probably one of those requests that sounds simpler to implement than they are, but it would be nice to have the option to use a scale of 0 to 1 to move through these. 0 = linear, 1 = exponential. 0 = easing in, 1 = easing out.
This would mean that the in + out option would not be available in this scenario, but that would be possible to math around in implementations. It would also bring about the option to animate the easings which would be fun!
The main purpose of this would be to neat up some nodes with separate curve modes and easings for 2d/3d/4d points which can look a bit excessive at the moment.
@MartinusMagneson, do I understand correctly that, as the input moves from 0 to 1, you’d like the curve type to change smoothly and gradually from Linear to Exponential / Easing In to Easing Out?
For Linear to Exponential — The formulas being used now include Linear = x, Quadratic = x^2, and Cubic = x^3. So my first thought is to make the new formula x^n, where n is a function of the input value. At 0, it would be x^1 (Linear). At 1, it would be x^10 or something like that. Would that work for you?
For Easing In to Easing Out — Easing In makes your outputs bunched up near the start time, while Easing Out makes them bunched up near the end time. Would halfway between Easing In and Easing Out be no easing (outputs are evenly spaced and not bunched up anywhere)?
Linear → exponential sounds great (although the nerd in me would love exp f(x) = x^x however useless it would be (disregard this)).
I think I initially assumed the easing would bunch up at where the time was in not set to linear. For instance that it would bunch up at .3 if easing were sat to .3 (VuoCurveEasing_Middle = 0.5), but both makes sense though.
This is where it gets out of hand, but perhaps a 3x2 matrix of options for the in and out easing could work?
in
linear
out
in
linear
out
This way, if both are set to in, the whole duration is calculated with an in-easing. In-linear gives in-easing until the center duration then linear the rest of the way. In-out gives in-out, and out-in gives middle easing and so on. In theory this could be hidden from stuff like the curve node while providing the same function as it currently has through the Vuo_curve function while giving a few extra options for other nodes. I assume that is on a different level of nodes to re-code if implemented though (unless it gets its own call at the bottom of the if-nest in VuoCurve.c; VuoCurveEasing_damnUnappeasableUsers(…)).
OK, here’s our plan. If this makes sense to you, @MartinusMagneson, we’ll open this feature request for voting.
Modify the Curve node so that the Curve and Easing input ports have the option to be changed to data type Real. (The node would still default to its current behavior.)
When the Curve port is a Real, the curve formula is based on x^n and the port controls n. (The port value could be n itself or a value in 0…1 that maps to n, not sure yet.)
When the Easing port is a Real, it has no effect when Curve is linear, and otherwise it controls where the easing happens (0 = easing in, 0.5 = easing middle, 1 = easing out).
The calculations will be available through the VuoCurve API, so if you wanted to implement more complex variations in custom nodes, you could use that as a starting point.
Trying to keep it relatively simple so it doesn’t require as many votes to justify implementing :)