A lot of bounce expressions rely on either setting parameters like frequency and decay, leading to guess work for when bounces will end or how long they'll last. Or the expression will settle the bounce on the last keyframe, giving you no real idea how fast the object will move before the bounce. This always bothered me.

Then this week on the Motion Design Slack group, someone was asking about getting bounce expressions to behave more intuitively. So I rolled up my sleeve and got to modifying an existing expression for inertial bounce (actually elastic). Here's the resulting code:

bounces    = 4;     //total number of bounces
duration   = .25;   //duration of each bounce in seconds
amp        = .05;   //multiplier for incoming velocity used in bounce
decay      = 3;     //exponential decay of bounce height

n=0;
if(numKeys>0){n=nearestKey(time).index;if(key(n).time>time){n--;}}
n==0?t=0:t=time-key(n).time;
freq=1/duration;
mult = (bounces-Math.floor(t*freq))/bounces;
if (n>0 && mult>0) {
    v=velocityAtTime(key(n).time-0.001)*amp; //velocity to use
    b=Math.abs(Math.sin(freq*t*Math.PI))*Math.pow(mult,decay); //bounce calculation
    value-v*b;
} else {value;}

Now this won't be physically accurate. Each resulting bounce would really be shorter in time as well. If that's what you're looking for, Dan Eberts has a physically accurate expression. And there's many other bounce tools like After Ease, Ease and Wizz, and Duik. However, this will give you a specific number of bounces, a set time for each bounce, and take incoming speed from keyframes for the object. This works great as an ft-toolbar button or a Text Expander snippet.