Copy link to clipboard
Copied
I'm looking for a way to access the possibly renamed "name" of a clip (TrackItem) in Track. Specifically, I'm not interested in the (clip as TrackItem).projectItem.name.
Searching the forums returned some old questions. One used the QE DOM, which does not appear to be accessible anymore. Another suggested exporting the project as FCP XML and parsing the information from the exported XML. This seems exceptionally kludgy and prone to mistakes. The "correct" implementation would probably include using the os.tmpdir API from io.js and passing that to ExtendScript, where you would then export the Project or Sequence and then parse the XML. This seems as though it could get pretty heavy, pretty quickly with complex projects. How performant are the XML export functions?
Also, has a better way to do this appeared? This seems like an oft-requested and (theoretically) simple-to-implement feature...
This now appears to be doable!!
As of Premiere Pro CC v12.0.0 (at least?), TrackItem objects have a read+write name property! Setting that value allows you to change the name of the clip instance in the sequence timeline!
Looks like this:
...// Example Video Clip name change:
app.project.activeSequence.videoTracks[0].clips[0].name = "Hello";
// Example Audio Clip name change:
app.project.activeSequence.audioTracks[0].clips[0].name = "World!";
// (NOTE: Both examples above require that a video/audio clip
Copy link to clipboard
Copied
No better way to do this has appeared.
How would such a capability (accessing the clip name) get used, in the workflow(s) you'd like to support?
Copy link to clipboard
Copied
https://forums.adobe.com/people/Bruce+Bullis wrote
How would such a capability (accessing the clip name) get used, in the workflow(s) you'd like to support?
We would like to present a list of clips along the tracks to the user. We'd like to do a combination of "intelligently" selecting some of those clips ourselves but then offering the user a chance to modify that selection. The problem right now is that the only way we can really identify them well is location-along-the-timeline (which isn't great) or by ProjectItem name (which is pretty terrible).
In the meantime, how stable is the FCP XML format? Which version of the format gets exported?
Copy link to clipboard
Copied
You could select every clip whose projectItem had the same path; that might be useful.
Clips added to a timeline are named with the projectItem.name, at the time the clip was added. Change the name in the project panel, and any new clips created from that projectItem will get the new name.
> How stable is the FCP XML format
Very, very stable. FCP XML spec version 4, shipped with FCP 7.
Copy link to clipboard
Copied
You could select every clip whose projectItem had the same path; that might be useful.
Not in our use-case, no. We are interested in selecting clips based on duration and timing. Showing the users a list of selected clips that all have the same projectItem name, even if they've modified them in their timeline with something more specific to that location in the track, is silly - they'd all have the same name and would be indistinguishable.
Clips added to a timeline are named with the projectItem.name, at the time the clip was added. Change the name in the project panel, and any new clips created from that projectItem will get the new name.
And yet, with the PPro APIs, they would all get the same name, would they not? The only name we can resolve with the current APIs is the name-at-time-of-call of a given ProjectItem that a clip (TrackItem) points to. Unfortunately this does not get us anywhere.
Is there something about clip names that's somehow sacred or really difficult to open up as an API? The TrackItem class does not currently have a name property, so there wouldn't be a collision...
Very, very stable. FCP XML spec version 4, shipped with FCP 7.
Good to know! Thanks!
Copy link to clipboard
Copied
This now appears to be doable!!
As of Premiere Pro CC v12.0.0 (at least?), TrackItem objects have a read+write name property! Setting that value allows you to change the name of the clip instance in the sequence timeline!
Looks like this:
// Example Video Clip name change:
app.project.activeSequence.videoTracks[0].clips[0].name = "Hello";
// Example Audio Clip name change:
app.project.activeSequence.audioTracks[0].clips[0].name = "World!";
// (NOTE: Both examples above require that a video/audio clip be present.
// This example skips standard safety checks for brevity.)
Bruce Bullis​, is this perhaps a missed item for the "What's new in 12.0" list?
Copy link to clipboard
Copied
Yep!
Copy link to clipboard
Copied
Looking to do the same. Ideally when you a track item clip
(e.g. app.project.activeSequence.videoTracks[0].clips[0] -- first clip in the first video track)
In our case we're using multicam clips and we're limited unable to know much more than the fact that we've got a multicam clip, its name, start, end opacity.
What would be helpful:
- Which source (master) clip of that multicam is currently showing in the timeline.
Building on sberic's notes, we'd be interested in accessing
- The name of the original master clip
- The name local name given to it in the timeline
- The label/color of the master clip
- The label/color given to it in the timeline
Ideally we'd have the ability to change the local-to-timeline clip name and label/color
What would we do with that:
Iterate through the timeline and update timeline clip colors based on any number factors:
- Source name
- Clips of certain durations of use
- Based on metadata (which clips, for instance have we tagged as being from a particular vendor that must be replaced)
- Clips with certain effects on then (color correction, resizing, audio effects etc etc.)
Effectively we'd like to be able to build customized functions that quickly, easily change the colors in a timeline to reflect all kinds of circumstances and workflows. That would help us enormously in quickly identifying, replacing, QCing, double-checking our work as we move through various stages of editing and delivery.
Right now we hit what seems to be an impenetrable road block, particularly limiting when we using multicam.