[Steve Bentley]

And here I thought Adobe had finally gotten over the memory management issues of by gone years. Sigh. Oh well, at least I no longer have to restart after a render. Render, purge, repeat!

[Steve Bentley]

I would say so – to my eye it needs more, but it’s not killing me. I don’t think any client would call you on it.

[Steve Bentley]

While I play with this….
Normally you want as uncompressed as possible to pull keys from. And a 4000kb/s H264 is a long way from that. You have lost so much chroma in the compression and there is so much artificial edge reconstruction going on in the codec that its just making your job that much harder. Keep in mind HD uncompressed (at 8bit) is about 186mb per second; where this clip is 6 seconds long and only 3.5 mb so theres a huge amount of data that’s missing. (and normally we’re working with either a RAW format or a 10bit color file or even better a 16 or 32 bit EXR file – these have so much color space you can hear an echo!)
So I think the combination of the creases in the fabric and the low quality of the codec bit rate is whats doing you in.
The screen doesn’t have to be moving to cause issues with the creases – if you look at compressed video really really really close you can watch two objects that overlap act like lava lamp blobs – as the front object moves, its edge seems to coalesce with details in the background, changing the shape of the edge. This also has to with how lenses and irises work (ok, what’s the plural of iris? iri?)
Let me try and pull a key and i’ll post the results. I’ll limit the test to only effects in AE.

[Steve Bentley]

There is definitely blur there on the overhead shot. I went to compare it to the first movie you sent which had none but its already been taken down.
I think any client would be ok with this level of blur. When there is none it sticks out like a sore thumb and if I have to really look it means there is probably enough.

[Steve Bentley]

To keep you locked into the CC an IC world, perhaps when you export to a bigger package like Cinema, instead of FBX or similar does the IC exporter put the animation on each vertex?
If you grin and bear loading in one model can you manipulate that model in C4D with the existing/imported bones or is the animaton baked in?

[Steve Bentley]

You can use trapcode to make envelop type things (or more accurately, origami type things – but then an envelop is just origami from a limited imgination, so it should work)
Heres’ link to an example
https://www.digitalartsonline.co.uk/news/motion-graphics/this-elegant-luminous-music-video-was-created-almost-entirely-using-trapcode-suite/

[Steve Bentley]

That sounds like it would be a good pipeline to keep things “live”. But because the motion blur is not an “effect” that could be shared between apps (it’s really the comp looking after that for you- perhaps premier has a shutter based motion blur on its comps?) it may need to be rendered in AE to make pixels that blur.

I just can’t believe, given Adobe’s history, that Premier and AE are that aligned/transparent to each other. Every effect would have to work in exactly the same way, in the same color space, with the same kind of motion graph editor. The stack order, easing algorithms, and blending functions would all have to be identical – even the way you can extend footage in AE: I’ll bet dollars to donuts can’t be done in Premier (and hence your shortening clip length)
Premier used to be an editor, so if you wanted complex motion or effects added you went to AE and rendered those and brought the resulting footage back in. The motion curves in Premiere were just so primitive you just couldn’t do the things you could do in AE. But that was back then, and perhaps I need to look at Premier again, especially since Final Cut has lost its mind.
It’s always seemed to be Adobe’s policy to keep every app’s specialty separate (it’s why we don’t have a stellar paint plugin in AE, which is desperately needed, even though Adobe owns the preeminent Paint package)

[Steve Bentley]

But you could get the value from SoundKeys and add it to the position of the flare – the higher the VU in Soundkeys the larger the increase in position would be and therefore (in a way, speed). The problem is (as we’ve been saying) the object you want to move is also the object you want to get the past position from to add the new value to.
You aren’t the first to try and crack this nut, even with sound – here’s a link to a past attempt – https://forums.creativecow.net/thread/227/32023
Dan Ebberts is the scripting guru in these parts and if he can’t solve it can’t be solved.
I’ve been trying to think of a way you could have two versions of the flare to help you out, one would be the one you see and one would be hidden but hold the value it was on from the last frame.
You would use something like this – positionOnLastFrame = Math.round(thisComp.layer(“layer 2”).position.value_at_time(currentTime-1)[1]) ;
Where: positionOnLastFrame is just a variable to hold the value of the position during the last frame, currentTime-1 is in frames (you have to do some conversion here as AE does time in seconds, so a frame is 0.033 seconds, but there are built in converting commands in the scripts hint window and it would just make the code here a mess to include and less understandable)
The [1] at the end retrieves the second parameter of the position data (the Y)

But the issue is that the expression is not leaving a trail of keyframes behind from which to grab the position data from currentFrame-1. Once the frame has passed the flare is in a new position and it has no memory of where it was.

Now if you could send the SoundKeys data to a null with an expression and then convert the expression to keyframes, you could do whats called an accumulator. Because you now have keyframes of the intensity of the range you are tracking in SOundKeys you can figure out for each keyframe where the flare should be. But you have to make loop in your code that will look at each frame from frame 0 up to the current frame (what Andrei was hinting at)
So at frame 0 you would take the initial position of the flare (which you would get from a keyframe on the flare at frame 0, then add the value of the sound key at frame zero. Then at frame 1 you would add the original position of the flare at frame 0 to the values you get from the SoundKey keyframes at frame 0 and frame 1. And you repeat that process for every frame. The higher the value from SoundKeys the farther the flare will move on that frame simulating a speed calc. You can even put a: if (valueOfSoundKey > someMaximum) { valueOfSoundKey==someMaximum); this would limit the top value’s affect on the position: ie 80 percent or 100 percent would move the flare by the same amount if someMaximim=80.
The problem is by the time you get down to 1 minute of music you will be doing 3600 calculations per frame and expressions are very slow in AE (compared to compiled C+ code)

[Steve Bentley]

In expressions, After effects only references the frame you are on and any data on that layer or other layers on that frame also. So you can’t say : make that go faster because the expression only knows the position on that frame and not where the object will be on the next frame or where it was the frame before. The only way to speed something up is to time warp the layer or move the keyframes or change the fps.
Lets try this another way:
Where did the keyframes come from that are on that layer? Did you do them by hand or are they a nodes on a spline?
Why do you not want to move those keyframes?
If we knew a bit more we might be able to help. Can you tell us what the data coming from Sound keys is supposed to do to the lens flare? Can you tell us what you want it to look like? there might be another way.

If you want a value from Sound Keys to control the speed of the flare going around the circle, think about it this way. For every frame sound keys will send a new value to your expression. So every frame will have a different velocity for the flare. Velocity on one frame is not speed. If you took still pictures of a race car going different speeds and made each picture a frame in a movie the only way you would know the car was going faster or slower is by the amount of blur in the background. Speed is distance/time. and there is no Time component on a single frame.
You need to tie the output of Sound keys to a position around the circle. the higher the value the farther the flare moves to around the circle. But if you get a different value on every frame from Soundkeys (and you will) the flare will just bounce around to seemingly random positions on each frame. If the flare was on a a straight line (think VU meter) you would see it “traveling” especially if it had a trail but without the trail it will just appear to be occupying a different position on each frame – that’s why VU’s “build up” otherwise it would just be a chaotic LED bouncing around.
Are you after a round VU meter? If so the the flare will need a tail so you know where the “zero” mark is and how far it traveled.

[Steve Bentley]

The keyframes are what cause the motion – the loop expression just makes it happen again and again.
So you can do a few things – squeeze the keyframes together (select them all and alt-drag them from the end toward the beginning, they will all scale in time correctly.
Or you can precomp that layer (move all attributes to the new comp) and then time warp the precomp shorter (or enable time remapping and shrink the keyframes on that, or use the time warp effect etc)