MOTUnation.com

I make an app that is a collection of some useful audio post production tools.

Today as an experiment I decided to see if I could also get an automated reconform applied to DP from a picture edit change list. I wrote a hammerspoon script that interprets a change list produced by my timeline compare tool & sends appropriate keystrokes to DP. It seemed to work pretty well.



The script is basically interpeting a change list produced by comparing two xmls for FCP X in my app.

If this is what I think it is, you will have scored a homerun, John.

Please tell us more about your app!

FMiguelez wrote:

If this is what I think it is, you will have scored a homerun, John.

Please tell us more!

The last release of my app added a compare tool that allows you to compare two picture drafts in XML (Premiere), FCPX XML (FCPX/Resolve) or EDL (Media Composer).

That produces a change list file (VCL/EDL) which can then be fed into a script that automates the process for various DAWs. Today I added DP to the script.

http://vordio.net/the-new-compare-function/

!

It basically makes it easier to deal with picture edit changes. So you can resync your audio edit to match what the picture editor changed. It shuffles the edit around to fit. Only relevant to working with video editors.

I'd have to see it in action in a practical setting, but I sort of understand where he is going with this. Or do I?

I'll hopefully get time next week to make a walkthrough video. Seeing the whole process might makes things clearer.

For now a simple example is this short film. A scene in the middle was removed between draft 8 and draft 9. So part of the audio sequence will now have to be removed and the 2nd half moved back to fit into the gap created.

How does this deal with cues that extend into the deleted region? Conversely, how does it deal with inserted scenes that may overlap into existing ones? Seems like a valuable tool.

Yes a region-based approach to reconform can't deal with overlaps well.

It will destroy some of the work at edges of changed regions. So those edges need to be checked. That's exactly why my script drops markers at those points. So you know where to check for potential issues. It still saves a lot of time over manually moving things by typing in timecodes though.

There is also a more fine grained item-based approach that is much less destructive and can deal with overlaps between scenes etc, but that is not possible with DP and most other DAWs either. To make it possible the DAW needs to have certain features to track items individually across drafts. It needs a documented open project format that can be manipulated plus the ability to embed tracking metadata in each item. In another DAW I do embed tracking IDs for each item in item notes, but DP doesn't have per-item notes, nor an open format, so I couldn't do that approach with DP.