How to export an EDL from a timeline using ExtendScript

[Premiopolis]

Is this possible?

[Premiopolis]

So far I've found

app.project.activeSequence.exportAsFinalCutProXML(fullPathToOutputFile, 1);

app.project.activeSequence.exportFramePNG(time, fullPathToOutputFile);

app.project.activeSequence.exportAsProject(fullPathToOutputFile);

app.project.activeSequence.exportAsMediaDirect(fullPathToOutputFile, outPreset.fsName,appencoder.ENCODE_WORKAREA);

But still looking for something along the lines of

   app.project.activeSequence.exportAsEDL(fullPathToFile,EdlSpecs);

Bruce Bullis​? Would you and team have any insights?

[Bruce Bullis · Accepted solution]

The PPro API offers no direct EDL output.

It had been more highly requested a few cycles ago, but (I'm told) those requesters decided to export FCP XML instead.

For what specific flavor(s) of EDL, are you hoping? To what workflow(s) would you like to feed EDLs, from PPro?

[Premiopolis]

The goal is to produce an accurate report of all items in a timeline -- all Source Names, Source TC Starts & Ends, Timeline TC Starts & Ends -- including (and this is key) those sources that have been sped up or slowed down in the timeline.

We got most of the way there by iterating all clips in the timeline using an approach hinted at here...

Samples/Premiere.jsx at master · Adobe-CEP/Samples · GitHub​

under the randomizeSequenceSelection method, so the algorithm works using logic along the lines of.... (abbreviated for clarity, not accurate syntactically)

app.project.activeSequence.videoTracks[0 thru numTracks].clips[0 thru numClips]["name","inPoint","outPoint","start","end"]
app.project.activeSequence.audioTracks[0 thru numTracks].clips[0 thru numClips]["name","inPoint","outPoint","start","end"]

That process, however, misreported Source TCs for timeline items that had been sped up or slowed down.

Notes/questions on that issue here...

Timeline Clip Properties inPoint and outPoint give inaccurate results when clip speed / duration not...

PPro EDL exports, by contrast report Source TCs accurately even for sped/slowed items BUT they can't be exported programatically.

I haven't fully tested exportAsFinalCutProXML, if only because parsing XMLs gets involved and laborious

The ultimate goal here is to be able to do timeline-based reporting, including footage use etc.

Frankly I'd prefer iterating the timeline over exporting/parsing an EDL, but I'll take either.

[Bruce Bullis]

Premiopolis  wrote

The ultimate goal here is to be able to do timeline-based reporting, including footage use etc.

Frankly I'd prefer iterating the timeline over exporting/parsing an EDL, but I'll take either.

Potentially helpful/relevant: The CueSheeter sample walks across the open sequence, looking for .wav files, and then writes a report.

https://github.com/Adobe-CEP/Samples/tree/master/CueSheeter

[Premiopolis]

https://forums.adobe.com/people/Bruce+Bullis  wrote

Potentially helpful/relevant: The CueSheeter sample walks across the open sequence, looking for .wav files, and then writes a report.

https://github.com/Adobe-CEP/Samples/tree/master/CueSheeter

Thanks for that one, Bruce.  Fascinating.

So getting your Active Sequence using

    qe.project.getActiveSequence()

          and

    app.project.activeSequence

Gives access to different sub-properties and methods?

In other words using your above-suggested "CueSheeter" approach I was able to access the following track clip properties:

name, start, end, duration, speed, reversed, type, mediaType, frameBlend, timeInterpolationType, scaleToFrameSize, multicamEnabled, numComponents

Whereas the approach I had been using gave props

name, start, end, inPoint, outPoint, duration, type, mediaType, projectItem, components

So on the one hand Cue Sheeter brings great news: speed -- just what I was looking for.

But it loses inPoint and outPoint, which is also key info.

We gained essential Source Clip Speed at the cost of the equally essential Source Clip TC In / Out.

I'll run some tests later, but in the meantime do you have any have-your-cake-and-eat-it-too for this?

Again, huge thanks.  Very helpful.

[Bruce Bullis]

Yes, QE DOM and normal DOM elements are completely distinct.

That 'cake' won't be ready until our forthcoming release.

[Premiopolis]

https://forums.adobe.com/people/Bruce+Bullis  wrote

Yes, QE DOM and normal DOM elements are completely distinct.

That 'cake' won't be ready until our forthcoming release.

Very much looking forward to that.  ETA?  Would be fantastic.

Here's a bit of additional discovery:

After building a routine that iterates a sequence using both the "Normal" and "QE" methods simultaneously, in the hopes of heaving and eating a cake of my own, the following issues popped up:

The QE approach seems to intermittently fail at returning proper Program TC and clip names.  Sometimes getting it right, sometimes wrong.

e.g. returning clip name "undefined" at times and getting completely the wrong start and ends that seem to relate to nothing

e.g. picking up readings on filler at seemingly random intervals

By contrast the "Normal DOM" approach seems to consistently iterate the clips accurately without fail.

When the QE approach does work it returns ever so slightly different Program TC results than the Normal DOM approach.

e.g. Where Normal Start time might give Program start of 20.0416666666667, the QE method, for the same edit shows it starting at 20.0416679382324, a little over a millionth of a second difference, so not practically different, but different.

Overall it seems the Normal approach seems more reliable and robust than the QE approach, and trying to run and coordinate both approaches in order to use the "speed" property from QE to fix the "inPoint" and "outPoint" error from the "Normal" is no easy task.

Would a Feature/Bug request be helpful here?