• | **Order of expression calculations - or link an already calculated expression**
on Apr 28, 2020 at 9:35:08 am |

Hi, Ive run into a small "problem". This is just for fun, but I wanted to have a small square "rolling" across my comp, so linking x-position and rotation in the correct way and calculating the y-position. This is what I came up with:

Position:

`h=thisLayer.sourceRectAtTime().height/2;`

x=value[0];

s=content("square_01").content("squarepath_01").size[1]/2;

[x,s-h]

Rotation:

`s=content("square_01").content("squarepath_01").size[0]/100;`

p=content("square_01").transform.position;

p/s

This works just fine. Now comes the tricky part: I wanted to add Dan Ebberts awesome Overshoot expression to the mix. This looks like this:

`h=thisLayer.sourceRectAtTime().height/2;`

x=value[0];

s=content("square_01").content("squarepath_01").size[1]/2;

freq = 3;

decay = 5;

n = 0;

if (numKeys > 0){

n = nearestKey(time).index;

if (key(n).time > time) n--;

}

if (n > 0){

t = time - key(n).time;

amp = velocityAtTime(key(n).time - .001)[0];

w = freq*Math.PI*2;

[x + amp*(Math.sin(t*w)/Math.exp(decay*t)/w),s-h];

}else

[x,s-h]

This gives the position a nice overshoot. But as soon as the playhead "leaves" the keyframed area and the x position is only calculated by the expression, the linked rotation does not work anymore/ stays at the value corresponding to the last keyframe. I worked around this problem by calculating the x-overshoot again in the rotation-expression, but it seems wrong to me that you have to calculate this twice.

So my question is: Is there a way to link a value **with** the calculations made by expressions?

• | **Re: Order of expression calculations - or link an already calculated expression** on Apr 28, 2020 at 6:25:04 pm |

It's not clear to me exactly what you're trying to do, but basically, if an expression refers to the value of the property hosting that expression, it only has access to the pre-expression value. Expressions on any other property accessing the value of that property only have access to the post-expression value. It's confusing, until you get used to it.

There is a hack, that used to work in some circumstances (but I haven't tried it lately) where an expression can publish its host property's pre-expression value for other expressions to use by using negative time. You would do something like this (let's say for the position property):

if (time < 0){

valueAtTime(-time);

}else{

// regular expression goes here

}

then the expression for any other property that needed the pre-expression position value would do this:

p = position.valueAtTime(-time);

to get the pre-expression position value. There is an issue about what happens at time = 0, but if that matters in your scenario, you can just add an offset to the negative time used:

valueAtTime(-time-1);

and correspondingly:

p = position.valueAtTime(-time-1);

I don't know if any of this is useful to you, and as I mentioned, I'm not even sure it will still work.

Dan

• | **Re: Order of expression calculations - or link an already calculated expression** on Apr 29, 2020 at 12:29:48 pm |

Hi thanks for your answer, I'll try to clarify more.

the rotation property seems to have a problem with referencing the post-expression position (in this case the overshoot). It works just fine until the overshoot, when it just stays at 0. I was wondering if this was the case because im referencing the position via an array (so "position[0]") since I a) only need the x-value and b) cant seperate the dimensions. But I guess its enough that its working when Im calculating the position overshoot in the rotation-expression again. :)