Is it possible to load a bin item in the Source or Program Panel?

[Premiopolis]

Is it possible -- I know it wasn't years passed -- to load a bin item in the source monitor by means other than file path?  I'd love to be able to load multicam source sequence into the source monitor.  Or a sequence into the record monitor.  Possible yet?

[Bruce Bullis · Accepted solution]

Nope, still need a path. I checked; your vote was already added to "Provide API to open a projectItem in the Source monitor".

[Premiopolis]

Real-world example of where programmatically loading either the Source or Program panel programmatically via bin item object, as opposed to via media path would be superior:

On a project with lots of Multicam sources, logged using Markers.  The logs breaks the footage down by key words, each representing a section of script.  There's no native PPro method of pulling up all the Markers containing that keyword.

Side note, check out

https://forums.adobe.com/message/9878523#9878523

https://forums.adobe.com/message/9878522#9878522

https://forums.adobe.com/message/9718505

which are hinting, suggesting at ways of evolving the "Search Bin" to

a) make it capable of representing results that are both Markers and Clips, and

b) More sophisticated and surgically precise in its ability to get at the intended content moments.)

In the absence of a more sophisticated content search system we started building our own which involves auto exporting per-clip (including per Multicam) Markers and importing them to an external, central database.  That gets us partway to our goal by allowing us to search for hits across all clips, and across all markers in one central searchable soup.  Currently we can click (either externally or internally using a PPro custom panel) to directly load results to the source monitor if and only if the source has a file path.  Not so if the Marker originated from a Multicam, sequence or any bin item NOT supported by a file path.

Our ultimate goal here is to have a system that allows us to log either clips (or beats within clips -- either as subclips or (preferably) Markers) using an array of search categories that can be queried with great sophistication.

PPro has all the right foundational ingredients to make this possible: Sophisticated Metadata control, Metadata Displays, Search Bins, the Custom-Codable ExtendScript API, but they don't yet quite play nice with one another.  Each route to editing glory gets stymied by some technical limitation -- like some cranky road troll that stands in the way with its knobby staff muttering "You shall not pass"!

In this case all that would be needed to cinch the solutions

a) An ability to load any bin item directly, as opposed to via file path

b) An ability to cue that item and play (haven't tested to see if this part is possible)

Bottom line: we're very close -- just 1 or 2 missing PPro SDK links away from an editing breakthrough.

[Bruce Bullis]

Cuing an item and playing it are possible today; your motivation for opening projectItems (and not simply file paths) makes sense.

[Premiopolis]

Another real-world example:

See eyali.av​​'s ​link here Associate source monitor and project item

Eyali's post reveals is how source media loaded via ExtendScript (i.e. via File Path) is a different instance than that same source media loaded via double-clicking it as a Project Item.

So while you can code ExtendScript to get and set Mark Ins & Outs of Project Items, you can't load those Project Items in the source monitor.  At best you can load the equivalent source media via File Path, but the clip that loads in the source monitor is oblivious to any Mark Ins & Outs set for the equivalent Project Item.

That significantly limits what's possible with ExtendScript.

By the way: This is not to suggest that loading a clip via File Path is inferior to the hypothetical/feature-requested load Project Item in Source monitor.  Loading via File Path is a great way to audition clips without actually adding them to the project.  It's like dragging a clip from the OS directly to the monitor: it won't be added to the project until you edit it into a sequence.

In other words, this is a have-your-cake-and-eat-it-too request. Ideally ExtendScript would offer two similar but different commands: the existing (albeit experimental/unofficial qe.source.openFilePath(FilePath)) command that loads File Paths to the source monitor, PLUS another yet-to-be-developed command that loads a Project Item.

[Bruce Bullis]

We understand why you'd want that.

We also now (as of 12.0, I think) have a non-QE-DOM call, for the simple case:

app.source.openFilePath(path);

[Premiopolis]

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

We understand why you'd want that.

We also now (as of 12.0, I think) have a non-QE-DOM call, for the simple case:

app.source.openFilePath(path);

I just tested in 12.0.0 (Build 224), to no avail.

both

app.source;

and

app.Source;

return undefined.

[Bruce Bullis]

GAH, sorry, I've used the QE DOM version too long.

app.sourceMonitor.openFilePath("/Users/bbb/Desktop/Example.mxf");

[Premiopolis]

Yes, thanks.  Just found as well and was going to post the same!  It works!  Thanks again.

So does that leave room in the world of QE for

qe.source.loadItem(SomeProjectItem)

and

qe.program.loadItem(SomeProjectItem)

?

Eagerly awaiting!

[Bruce Bullis]

QE DOM has been packed in mothballs for long-term storage; we won't be adding to it.

Any "provide API to open a projectItem in the source monitor", will show up in the "full light of day", normal, vanilla DOM.

[Premiopolis]

I'm hardly partial to QE.

app.sourceMonitor.loadItem(SomeProjectItem);

and

app.programMonitor.loadItem(SomeProjectItem);

(frankly spelled however team Adobe wants) would be warmly welcomed additions.

[eyali_av]

Premiopolis  wrote

So while you can code ExtendScript to get and set Mark Ins & Outs of Project Items, you can't load those Project Items in the source monitor.  At best you can load the equivalent source media via File Path, but the clip that loads in the source monitor is oblivious to any Mark Ins & Outs set for the equivalent Project Item.

That significantly limits what's possible with ExtendScript.

Premiopolis  - you'd just put that perfectly!

If i may, I would like to add the user perspective, that shows the current limitation: 

1. User interact with panel for retrieving information in its domain.

2. This eventually will be resulted in a clip or other media which he needs to be edited in premiere - so he would like to open it and start his work - editing the clip.

3. This editing work he just did - the panel needs to be aware of! so this newly created information (which resulted from the editing phase) needs to be reflected in the panel.

And the limitation as I see it is - we can do the "open" part of step 2 (easily by `app.sourceMonitor.openFilePath(somePath)` ) - but the editing job which can be done in the source monitor cannot be retrieved (step 3).

Maybe i just need to forget about assume editing job in source monitor, and expect users do it within the timeline?

Have anyone managed to "serve" a file in a timeline in an API kind of way?

[Premiopolis]

eyali.av  wrote

Maybe i just need to forget about assume editing job in source monitor, and expect users do it within the timeline?

Have anyone managed to "serve" a file in a timeline in an API kind of way?

By "serve" do you mean automate editing to a timeline?

If so try here Samples/Premiere.jsx at master · Adobe-CEP/Samples · GitHub

and search for functions insertOrAppend and overWrite for a few clues

[Premiopolis]

Real-world use case here: Currently cutting a show with 4k footage shot in LOG, meaning we have to color correct.

Imagine a custom panel that can take the clip name (or better, allows the editor to actually click Custom Panel-embedded script) to load the associated clip in the source monitor.

That we can do.

But... big problem: Because source media programmatically loaded into the source monitor is not the same thing as a project item loaded in the source monitor -- even when the programmatic media and the project item reference the same media.

So any color correction done to the project item is missing from the ExtendScript-loaded media.  And, in fact, it's not possible to color correct ExtendScript-loaded media.

So we're sitting on a really cool, unique-to-Adobe opportunity: clickable scripts, but we can't integrate it with a LOG-shot workflow.

[Bruce Bullis]

(Still) understood. That feature request is still near the top of the backlog.

[Premiopolis]

[Bruce Bullis]

Your beseeching attitude (and presumed willingness to test any pre-release builds containing relevant changes) has been noted, in the feature request.

[Premiopolis]

Of course.  My goal: codable everything Adobe.

[Premiopolis]

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

Your beseeching attitude (and presumed willingness to test any pre-release builds containing relevant changes) has been noted, in the feature request.

Does the latest release of PPro include a change to the SDK?  I've got a PPro project loaded with more than 500 items, an iron-clad naming convention, and a script formatted to handle automation

Any way to select a projectItem, set its mark in / mark out and append it to the end of a Sequence?

I'd love to rough-assemble 1/2 hour of script in 2 minutes.

[Bruce Bullis]

12.1.2 doesn't add the ability to open more types of projectItem in the Source monitor.

However, you CAN set the in/outs of a projectItem, and append it to a sequence.

[Premiopolis]

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

However, you CAN set the in/outs of a projectItem, and append it to a sequence.

Are you referring to the insertOrAppend & overwite functions in Samples/Premiere.jsx at master · Adobe-CEP/Samples · GitHub ?

It looks like the object first used by way of example there is presumed to be a projectItem, correct?

Will test soon.  Looks brilliant.

[Bruce Bullis]

Yep, 'first' is the first item in the project; you can use the project panel selection, and/or select projectItems however you want.