[Filip Vandueren]

As a challenge I hacked something together using text-animators.

here’s a quick screengrab of me playing around with it:

https://www.dropbox.com/s/k0ro3n3pv9zyxy7/Screen%20Recording%202020-09-09%20at%2000.22.05.mov?dl=0

I hope the usage is clear. It’s just a proof of concept.
Basically any number of precomp-layers can ask the text-layer where the hidden bullet-points are by asking for the sourceRect at a negative time. sourceRectAtTime(-3) gives you the sourceRect of the 3rd bullet.

of course: caveat: this is just a hack, very slow (for my standards), and maybe not useful for you in production, but it was fun to build.

Ideally this would be combined with a script that disables all the expressions once the correct positions are calculated.

project-file: https://we.tl/t-R9FDYORftO

[Filip Vandueren]

As a rule, try to avoid mp4 and other heavily interframe-compressed codecs.

Yes MP4 H264 is convenient and small for playback and distribution, but for a compositing application it is a computational nightmare.

Premiere does a lot more “oh this is just unaltered footage, I’ll just stream it to the screen”, whereas After Effects will convert each and every frame into an uncompressed RGBA image, even if you just place it in your timeline without effects.

Premiere is also a bit more forgiving with variable framerate mp4s, whereas in After Effects that can cause a lot of straneg problems.

[Filip Vandueren]

If you’re comfortable with a python-script, there’s this:

https://github.com/ftarlao/check-media-integrity

[Filip Vandueren]

If you make a pre-comp where all the needed footage of the photographs (be they stills or movies) are layed out all in sequence,

-> then you can always reuse the same composition, but with different values for time-remap.

If more things need to change than just the content of those photos, you can also look into master properties, they can help a lot with not having to duplicate precomps.

[Filip Vandueren]

I think that’s exactly what the “protected regions” of a precomp are useful for,
so it wouldn’ t need expressions

https://helpx.adobe.com/after-effects/using/responsive-design.html

[Filip Vandueren]

You’d have to do a replace with regular expressions in stead of strings.
read all about them here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions

for example:

t=text.sourceText.value;
t.replace(/\w/g, "b");

would replace all \w = “word” characters by the string “b”
(but it would keep whitespaces, punctuation, symbols some accented letters,…)

or

t=text.sourceText.value;
t.replace(/[^ \r\n\u0003]/g, "b");

would replace anything that’s NOT (because of the [^…] syntax) a space, a carriage return, a newline, an end-of-text meta character (unicode 0003 = shift-enter) by the string “b”

[Filip Vandueren]

Are you sure that’s the case for every path with a space, and not due to your script not having the privileges to write to this specific path.

[Filip Vandueren]

Once you’ve created the file with a path, you can get different properties of that file such as

f.fsName; (dependant on your platform)
f.fullName; (independant of platform)
(on my mac these two are the same, I suppose on windows fsName would use reverse slashes)
f.absoluteURI;
f.relativeURI;
f.path;
…

But if you’re just asking what “f” is -> it’s an object representing a file,
and if you $.writeln(f) it’s the same as $.writeln(f.toString)
which happens to return f.absoluteURI.

I think you want/expact f.fullName;
although to just manipulate the file (read from it or write to it), there’s no need -> just use f

[Filip Vandueren]

But why do you need to change the %20?
The File object points to the File, does it not?

What do you mean by “place the string into File()” ?

[Filip Vandueren]

Sure, it does use a few different of methods:

pos = l.toComp(p.pointOnPath(tr/100) + extra_margin);

p was a reference to the shape of the line you drew (path)
tr was a reference to how far the End-parameter of the trim Paths Effect was set.

p.pointOnPath() = is a method that returns the pixel coordinates of a point along a given path (p).
At 0 it’ll give the position of the vertex, at 1.0 the position of the last vertex (or the first again, if the path is closed), and in between it’ll give points along the path.
It is very close to what “Trim Paths” does visually, but gives us coordinates.

Trim Path however goes from 0-100, so we divide by 100 to get values between 0 an 1.0

p.pointOnPath(tr/100) + extra_margin -> this would give us the pixel coordinates of where the line stops + some extra pixels higher (extra margin).

However: these coordinates are relative to the layer the path is on, we cannot just use this coordinate for another layer ‘s position and suppose they are the same: the layer where the coordinates comes from could be sacled, rotated, parented,… for every layer an ‘internal’ coordinate like [100,100] can mean a totally different pixel on screen.

layer.toComp([x,y]) fixes this: it is a “layer space transform method” that gives us the actual position in the comp of a position ‘inside’ of a layer.

There might be other factors of why that position would still note work as the precise position for another layer (if it’s parented form example), but that is fixed in the next line with a fromComp(), which does the inverse of toComp()