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!

Why Premiere Pro could use scripting

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?

Tagged , , , , . Bookmark the permalink.

4 Responses to Why Premiere Pro could use scripting

  1. Steven says:

    Hi Bart, if there would be some 3rd party scripting language for Premiere Pro available, would you buy it?
    But I have to admit that it wont be as fast as the native ECMAScript in After Effects.
    And what do you think, how many editors would buy a license for such an app?

    • BartW says:

      Hi Steven,

      It all depends on the pricing, what exactly it could do, and how convenient/inconvenient would it be to use it. But I’m open to the possibility. As far as target market – not many at first, but when the scripts get developed which can do what Premiere can’t do, I guess quite a lot. I recommend taking a look at the download numbers on my page, and draw your own conclusions from there.

  2. Steven says:

    Quite a bit, I see you’re running your site almost 2 years.
    That’s the first time I ask for opinion about the value of a Premiere Pro scripting language, thanks to your Blog Post.

    Since Premiere 6.5 (the old non-pro version) I’m trying to automate tasks and currently it is still far from perfect.

    Already doing tasks like Track and Clip manipulation from Keyboard, Removing Gaps, jumping with playhead +/- 10/30/60 seconds/minutes, collecting timecodes, get/set timecode, variable-speed scrubbing from keyboard, all of the commands from main menu and context menus are available, ability to send commands with keyboard while Save Project dialog is active, a lot of custom editing timesavers, quick audio gain modification, multiple hot-keys per command, combined hot-keys, mouse gestures and so on, the possibilities are endless, but of course with some hard-to-overcome limitations.
    In plans – return of the CS5 jog/shuttle (there was a long thread at adobe forums people craving about), xml parsing to determine selected clip type and properties, keyframe generation, etc.

    I was thinking about creating the Scripting language for Premiere Pro a few years ago, but didn’t had the time. Now I have a few months, but I’m not sure whether it will fire.
    The second reason that I didn’t started the project is that I believed that Adobe will include their ecmascript to Premiere Pro too. But that didn’t happened and I don’t know about their plans for CS7. I have to research about this, maybe asking Kevin Monaghan or finding somebody from the Premiere Pro Developers Team who could confirm that there are no plans for scripting.

    About pricing, I would be happy if you will be a beta-tester or a partner to help with this project.
    It would be great to start a project like digitalrebellion.com or pluraleyes.

    One more thing, currently it’s for Windows only.

    • BartW says:

      I’d be happy to collaborate, shoot me an email and we’ll talk. All the details are in the “about me” page.

      The main server has been running for that long, but the Creative Impatience itself started in June last year.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.