[Steven Kutny]

Going with this for position… Frame rate must dictate how bounce lands on the base line when tweaking the frequency… Sometimes a higher or lower freq throws off the hit. Trial and error but it’s all good.

freq = 1.0;
amplitude = 500;
decay = 1;
t = time-inPoint;
posCos = Math.abs(Math.cos(freq*t*2*Math.PI));
y = amplitude*posCos/Math.exp(decay*t);
position - [0,y]

[Steven Kutny]

Fixed the scale problem using this code form your site:

maxDev = 13; // max deviation in pixels
spd = 30; //speed of oscillation
decay = 1.0; //how fast it slows down

t = time – inPoint;
x = scale[0] + maxDev*Math.sin(spd*t)/Math.exp(decay*t);
y = scale[0]*scale[1]/x;
[x,y]

I repositioned my null to where it should have been, at the bottom of my ball, and now the sin wave feels correct. Thanks again!

[Steven Kutny]

Hi Dan,

Grateful if I could get your input one more time with this. I notice that the look of the animation changes depending on the layer order. If I create layers about them, or if I reorder the layers in my comp, their animation shifts.

I removed the (index-1) part from this line: t = (time-inPoint) – delay*(index-1); which fixes that problem, but now I see the bouncing doesn’t always land on the same base line with a 0.1 delay; the hits will be slightly higher than the final resting position, unless I change the delay to 0.5 or something higher. Just making sure my change to that line is correct for this expression.

Also wondering if there is a way to match up the squash & stretch expression on scale to the bouncing? I’m getting varied results. Not sure if I need to match the delay to the delay on position or the difference between the decay and masterDecay…

Many thanks!

[Steven Kutny]

Perfect! Thanks so much for this Dan, it is a big help 🙂

[Steven Kutny]

Thanks for the quick response Dan! This works for the subtle variations, but what if I wanted to offset the entire animation by 10 frames without having to pre-comp? No variation, just frame/time offset.

[Steven Kutny]

Hey Jason,

I uninstalled my Java after reading this, but unfortunately the problem still persists. Here’s a link to the main discussion on Adobe’s forum:

https://forums.adobe.com/message/5534970#5534970

Sounds like they’re getting close to a solution so fingers crossed!

[Steven Kutny]

Thanks for responding Todd, this is a big relief. Do you think the menu delays also tie in with the keyboard shortcut delays? In general, the use of any shortcut that jumps through the timeline is sluggish. Examples are “page up/page down” step throughs, or “J/K” commands to snap at key frames.

[Steven Kutny]

Wow, that fixed it! I just did several tests with two different heavy projects and each passed. Can’t believe I missed that switch before, thanks for narrowing this down Todd, much appreciated.

Steven Kutny
Designer/Compositor
http://www.stevenkutny.com

[Steven Kutny]

Hi Todd,

I was excited to install the latest update for CS6 today (11.02.12) but unfortunately I’m still experiencing the same frustrating lag using the shift key flow chart. Any word on a future fix for this?

Thanks,

Steve

Steven Kutny
Designer/Compositor
http://www.stevenkutny.com

[Steven Kutny]

Thanks for the response Todd. If it helps any, the lag is most apparent in heavier projects with many nested compositions and effects applied. In smaller projects with less comps it seems to work better. Oddly enough, if I were to jump into several nested comps and click on the mini-flow shortcut next to search bar it opens the flow immediately. So far, this method has been my work around but I’d still love to get back the snappiness of tapping shift.

Steven Kutny
Designer/Compositor
http://www.stevenkutny.com