[Paul Beckett]

Hi Filip,

Thank you for the help – Hopefully I’ll get the chance to play with your script this week and see what results I can get, and report back.

Thanks again!

P.

[Paul Beckett]

Hi Filip,

Thank you for your comments.

Yeah I see how limiting the expression to count beats could cause more issues. I’ve played around with baking the expression to keyframes and while it does work, it takes a long time to write the keyframes, which would be fine, if, as you you mention I needed to do it only once, but I do need to make small adjustments occasionally and currently the amount of time it takes to re-bake the expression after a change is a problem (the comp is about seven minutes long).

That said I was also experimenting with Dan’s other expression which triggers at a certain threshold which gave me some interesting results but still I have the issue of it being slow to calculate when scrubbing through the timeline. It was with this expression I was wondering if limiting how far back it looked would work. Dan describes the expression as looking backwards in time frame by frame until a threshold transition is found – if that is the case, could it be possible to limit the expression to say twice the length of time between the current time and time of the previous transition? Or would this cause the same problems of stagnation which you described?

At the moment I’m just trying to understand the limitations of the these expressions or expression built on them before go too far in one direction.

Thanks again!

P.

[Paul Beckett]

Hi Dan,

Sorry for slow reply and thank you for the pointers…..

So over the last week I have been playing around with the expression from your site which you recommended, plus your “Triggering an Expression With Audio” expression. Both of which I was able to get some interesting results from.

However as per your warnings the expression would start to take a long time to update when scrubbing through the timeline, with the update time becoming quite an issue if the comp was plus two minutes or more. Although this didn’t seem to be an issue during ram preview.

I was able to workaround this by wrapping the main expression in an if statement linked to a checkbox control, then I could switch off the expression if not using it at the time. This led mo to think that there was probably a way to automate the switching on or off of the expression – although that wouldn’t resolve the issue of slow update times when the expression was switched on.

In turn this led me to wonder if there was a way to limit how far back the expression looked when making the calculations – maybe using the in and out points of the Work Area, a layers in and out points, or markers, or even hard code it into the expression so it would only look at the previous sixty frames for example. I imagine though that this isn’t doable as I would have found some examples or tutorials on the subject.

My next step is to see if I can do something using Scripting or bake the expression to key frames, although I’m not sure if this would work or be any quicker because my initial experiments so far have also suffered from the issue of it taking a long time to write the keyframes or update.

Anyway, onwards and upwards…. and thanks for the advice so far.

P.

[Paul Beckett]

Hi Dan,

Thanks for the quick response and help as always.

I tried what you suggested but run into problems if I then wanted to evaluate if the layer was either the 1st, 2nd or 3rd in the sequence within the same expression – so, index%3 and index%2 would both return true for layer six as an example, thus not giving me the result I was looking for. However it got me thinking and after some tinkering I realised I need to set the index%3 as a variable and call it in the if() statement and not wrap it within it.

This is what eventually worked for me – this also means I can quickly add conditions, like if the layer is the fifth layer in the sequence.

idObjectIndex = effect("fauxIndex")("Slider");

idThirdLayer = idObjectIndex % 3;

if(idObjectIndex <= 0 && idThirdLayer == 0) {
000;
} else if(idThirdLayer == 1) {
111;

} else if(idThirdLayer == 2) {
222;

} else if(idThirdLayer == 0) {
333;

}

Thanks again!

P.

[Paul Beckett]

Hi Alex,

That did it! Thanks so much for taking the time to help out!

P.

[Paul Beckett]

Hi Dan,

That works great, thank you. Another hole in my understanding filled.

Cheers,

P.

[Paul Beckett]

Hi Dan,

Thank you again for the quick reply – I will give that a go.

Cheers,

P.

[Paul Beckett]

Hi Dan,

Thanks for the quick reply and the help. I’ve tried what you suggested and also corrected my type-o, however the problem persists. It works fine on the first instance of the text layer named “myTextLayer1” but skips the remaining layers in the comp with the exact same name…

I think something is causing the code, after it has executed on the first instance of the text layer, to jump into next comp before it iterates through the remaining layers, I just can’t figure out where that is happening at the moment.

If you had any further thoughts on this I’d really appreciate it, in the meantime I’ll keep on chipping away at this problem and hopefully find the answer.

Thanks again,

P.

[Paul Beckett]

Hi Kalle,

Works a treat, thank you.

I did eventually work out another method but I think your version is much more efficient!

Thanks again.

P.