Tag Archives: scripting

Farmacie online Farmacia Millefolia cu cele mai bune prețuri din România. Samsun'un en güzel escort bayanları samsun escort ile size unutulmaz bir deneyim sunuyor. Hemen ziyaret edin!

Creating Thumbnails Has Never Been Easier

By | | , , ,
Leave a comment

One of the byproducts of my work on THAT Studio Panel extension for Premiere Pro and After Effects has been an After Effects script that would generate a massive amount of thumbnails for video files. The initial idea to use it to prepare Panel assets did get scrubbed along the way, and we never got to using it in our automated workflow, but I believe it was too valuable to go to waste. Therefore here it is – name any way that you want to generate frames from your After Effects compositions or video files, and Master Thumbnailer will do that for you.

see more →

Layer Stripper – It’s Not What You Think It Is

By | | , , ,
1 Comment

As I’m getting ready for this year’s NAB, I think it’s great time to release a new nifty tool for After Effects – CI Layer Stripper. This script deftly removes all unused layers from your project – the ones that are not visible, and not referenced by other layers as parents, track mattes, or even simple expressions. This will allow you to trim and collect these items in your project which are actually being used.

see more →

Finally a Viable After Effects Archive Solution

By | | , , ,
Leave a comment

While developing Conform Studio I stumbled upon an application of the CS Extract script which I considered interesting, but did not have enough time to code and test properly. It was only a matter of time when other people attempted to use the Studio in this manner, therefore I even included a note in the manual about it. see more →

Move That Anchor!

By | | ,
Leave a comment

Being a casual After Effects user I find myself sometimes creating an animation path only to find out that I need to later reposition the anchor point of the layer to add rotation or scale. To my surprise, even with the abundance of AE Scripts on the market, I could not find a simple tool to remedy this problem. So I wrote one myself. see more →

Nuke Studio For After Effects

By | | , ,
2 Comments

When I first saw the demonstration of Nuke Studio shown on NAB, with each new feature I was thinking: yes, this is exactly as it should be done. This is precisely how Dynamic Link should work from the get go in Adobe applications. Congratulations to The Foundry for making it happen. I wish I could afford your tool 🙂 see more →

The Strange Maths of After Effects Timecode

By | | , , ,
2 Comments

For past few weeks I’ve been developing for That Studio a number of scripts for After Effects which are supposed to make one’s life easier, when dealing with an edit in Premiere that requires handling of more than a couple of VFX shots.

One thing that surprised me is that you can’t access layer’s timecode directly using scripting, even though you can do this using expressions. At first I thought that I can use the Time Remap effect to do this, since its values are supposedly shown as a timecode. But a brief experimentation shows that it’s not the case. Time Remap values are given in seconds from the start of the layer regardless of its timecode. Ouch.

Therefore one has to resort to a brutish hack to obtain the layer’s starting timecode: create a text layer, add an expression that reads the layer.sourceTime value and assigns it to the text, and then read the source text in the script. That’s hardly an elegant solution, and it would be so much better, if the layer.sourceTime was supported not only for expressions.

Perhaps I could live with it, but on top of it there is a nasty bug hidden in AE, and it can bite you rather hard, if you’re not careful.

You might be familiar with the fact that when you precompose a single footage layer, and choose to leave the effects in the main composition, the precomp will have the length of the whole footage file, and will inherit the exact timecode… more or less so.

You might not be aware, that if you are using 23.976 fps frame rate, the timecode might be off by a frame or even two when you attempt to render this layer – which you will notice only if you open the file, because even the render queue will show the correct timecode value. You can mitigate this by manually entering the starting timecode in the composition settings window.

The real problem begins when you are trying to set this timecode via scripting. Let’s say you want the composition to start at 20:20:51:22, which at 23.976 fps translates to 73325.2419085752. When you assign it to the desired composition, the internal AE procedure will truncate it to 73325.2421875, which will result in the timecode which is not frame accurate, and even though it is displayed correctly in the composition, it is incorrectly rendered and written to file. You can check it yourself by running the following script on a selected composition (make sure to first enter 20:20:51:22 into the Start Timecode of the Composition Settings dialog):

c = app.project.activeItem;
a = c.displayStartTime;
alert(a);
c.displayStartTime = a;
alert(c.displayStartTime);

Note, that the value changes by the sheer fact of assigning the code to the composition start time. My supposition is that the internal workings of AE convert the double value into a float, thereby reducing the precision at higher values. That’s definitely not nice. Depending on how critical the timecode is for your application, it might rule out automation of certain tasks, and make it more troublesome to render – you have to always manually enter the starting timecode, even if you precompose. I have not found a way to reliably code around this bug.

The conclusion so far is: forget about accurate timecode renders from AE, especially if you are using 23.976. 29.97 or higher fps and do not start from a full second. Lower integer frame rates seem not to be affected so much, as are easy dividers (12 for 24 fps, etc.). Unfortunately, even if this is fixed in the future releases, it still means that you can’t use scripts that rely on this feature for earlier versions of AE.

Why Premiere Pro could use scripting

By | | , ,
4 Comments

I’ve been testing the workflow from Premiere Pro to DaVinci Resolve (similarly to other more renowned people). For many reasons I want to avoid sending a flattened file, instead relying on XML interchange, and a few annoying simple issues make it pretty inconvenient:

  1. We’re using XDCAM EX in mp4 wrapper and NXCAM (AVCHD) files which Resolve does not support. Transcoding is necessary although it’s the subject for another entry.
  2. Time remapping in Resolve is much worse than even in Premiere, not mentioning After Effects. All speed changes should be rendered and replaced before exporting XML.
  3. Some effects should be rendered, but transitions should be left untouched.
  4. All Dynamic Link clips should be rendered and replaced.

Doing these things manually takes a whole lot of time, and is very prone to mistakes. This is a perfect example when a simple script would make one’s life so much easier. The script would:

  1. Traverse the timeline, looking for clips having properties mentioned in points 2-4.
  2. Create a new video layer or a sequence, whatever would be faster.
  3. Copy the clips there one by one and queue export for each to desired codec, encoding timecode and track either in metadata or the name.
  4. After the export is done, it would import the renders, and replace old clips with the new ones.

Alternatively, I could have one script to export (1-3), and another to reimport (4).

See? It’s relatively simple. The possibilities of scripting are almost infinite. For example, I could also change all the time remapped clips automatically into Dynamic Linked AE compositions and render them using its superior PixelMotion algorithm – although I would rather appreciate Adobe including it in Premiere itself, getting rid of the old and awful frame blending. I could even attempt to change them to their Twixtor equivalents, although I must say that my experience with this effect is pretty crashy.

I looked at SDK for Premiere Pro to see if I could write a plugin that would make this job easier, but as far as I know such possibility does not exist. Plugin architecture for Premiere is pretty limited, and compartmentalized, and using C++ for this seems like a bit of an overkill.

Adobe, please support scripting (JavaScript, Python, or any other obscure language) in Premiere Pro. This way users will be able to create their own tools to solve inefficiencies of the program, and your job will become much easier. And Premiere Pro will prosper and develop much quicker and much more effectively. Besides – you don’t want FCPX to overtake you, do you?