Is there a way add custom properties to Timeline clips?

[Premiopolis]

Is there a way add custom properties to Timeline clips?

So something along the lines of...

(function(){
  var ThisTimelineClip=app.project.activeSequence.videoTracks[0].clips[0];
  ThisTimelineClip.MyCustomComment="Test";
  ShowProperties(ThisClip);
})();
function ShowProperties(ThisObj){
  for(var ThisProp in ThisObj){
    $.writeln(ThisProp+": "+ThisObj[ThisProp]);
  }
}

Currently this Returns:

  duration: [object Time]

  start: [object Time]

  end: [object Time]

  inPoint: [object Time]

  outPoint: [object Time]

  type: 1

  mediaType: Video

  projectItem: [object ProjectItem]

  name: NameOfTimelineClip.mxf

  components: [object ComponentCollection]

but not

  MyCustomComment: Test

[Bruce Bullis · Accepted solution]

You can add custom properties using XMP, but they won't be visible elsewhere in PPro's APIs.

[Premiopolis]

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

You can add custom properties using XMP

Custom properties using XMP to a Timeline Clip (as opposed to a projectItem)?

If so, how to do?

The goal here would be to push custom info into timeline clips, and have it save to the clip instances in that sequence, not project items.

In that way custom info written to one sequence would not affect existing sequences even if they share the same source clips.  A duplicate sequence would carry custom info of the original, but the two would be able to diverge from the moment of duplication forward.

Use case:

We've got a numbered script.

We want to reference the script in the sequence: each clip in the timeline representing one line of script.

So we create a custom property: scriptLineNumber and push the script numbers into the sequence.

Might even create a custom property: scriptText and push the actual text into sequence.

As the sequence gets edited the embedded info carries with the sequence clips.

Effectively, a re-edited sequence could be used to output an updated script.

Why not just do this with Sequence Markers paired with the Ripple Sequence Markers?  Because Markers don't carry with timeline Clips when they are copy/pasted, requiring extra effort the keep them paired.  More on that here: https://forums.adobe.com/thread/2516172

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

but they won't be visible elsewhere in PPro's APIs.

It wouldn't need to be visible to other parts of the API, as long as the Custom Panel can write to the timeline and subsequently read it back even after quitting and re-launching the project.

[Bruce Bullis]

Custom properties using XMP to a Timeline Clip (as opposed to a projectItem)?

No, you're correct, the XMP is specific to the projectItem. There's no good way to limit 'custom info' to a given trackItem (clip).

[Premiopolis]

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

Custom properties using XMP to a Timeline Clip (as opposed to a projectItem)?

No, you're correct, the XMP is specific to the projectItem. There's no good way to limit 'custom info' to a given trackItem (clip).

Argh.  So frustrating.  Having access to that would open up the possible of all kinds of Custom Panel functionality around Scripts, Change Notes, Change tracking, changing / nuancing the names of trackItems.  Feature request?

[Bruce Bullis]

DVAPR-4209284, "Provide mechanism to attach custom properties to individual trackItems".

[Unlikely for this fall.]

[Premiopolis]

Thanks!  Will wait patiently.

[Premiopolis]

Alternatively: Long shot:

This could conceivably be made to work if there is a way to get a UID from each trackItem in a sequence.

In that case it wouldn't be necessary for the Sequence to store the info.  All the relevant info could be handled externally in the Custom Panel.

I haven't seen any ability to get any kind of UID out of a trackItem using the ExtendScript, but nonetheless asking -- on the off chance.

[Bruce Bullis]

Oddly enough, I already had TrackItemLiveObject.cpp open in XCode; no dice.

[Premiopolis]

So maybe in a addition to

DVAPR-4209284, "Provide mechanism to attach custom properties to individual trackItems".

Another request for obtaining trackItem.UID of some kind.

On perusing the raw XML of an PPro .prproj file, assuming I'm understanding it at all, it looks like each trackItem has an ObjectID as well as an ID.  Perhaps one or the other of those the ID that might do this.

Here's the actual situation I'm trying to deal with:

- Producer presents script.

- It's a fine script BUT it is devoid of relevant Clip Names and time codes.  The clip names are descriptive and idiosyncratic, not based on media file names, and the time codes are all 0-hour based on using QuickTime Player as if it were the second coming of crack.

- No amount of "hey this creates workflow issues" nor "this will blow your schedule / affect the budget" nor "this is a collaborative effort that requires coordination" will convince this producer otherwise.  This producer is not (yet) replaceable.  Clubbing this producer with a large raw wet fish will probably not work either.

- So... using a series of techniques the script was converted into a grid with accurate clip names and time codes along, each line numbered.

- That updated sequence can be presented inside a Custom PPro Panel, and is even clickable.  It won't load to the source monitor (note our previous back-and-forths at Re: Is it possible to load a bin item in the Source or Program Panel? ) but it is possible to select items using ExtendScript and either have it appear in the Project Panel preview area,i.e. This handy thing...

or, using a MetaData approach, have it appear in a Smart Bin.  Neither of load projectItem to Source Monitor, but overall clicking a script to edit is saving huge amounts of time.

- The problem now: Producer will not make changes based on the the updated, formatted script.  Insists on using the original script in all it's "will not reference anything outside of producer's mind" glory.  NOTE: This producer is not unusually difficult but rather standard-issue, so dealing with this one is dealing with many.

- The goal now is to continue to take these hard-to-work-with scripts, update them, push them into PPro, and be able to get from updated script to "that previous point in sequence" and speed through the change process.

- This UID issue would help this particular issue, but the number of use cases we could put this to is rather prolific.

Imagine: An in-panel script that cues up and highlights active script line based on which clip the playhead crosses -- whether scrubbing or playing in real time.

[Bruce Bullis]

DVAPR-4209287.

Well-explained.

[Premiopolis]

Another, hopefully motivating, thought: There is very little in the way of software out there that forms a connection (let alone a live-in-real-time connection) between written scripts (text) and edited sequences.  Avid has a few tools, but I don't think they're heading in this direction.  PPro is one or two ExtendScript properties away from this being not only possible but robust.

[Trevor_Asq]

So you are nearly able to take paper (word-processor) edit from transcripts & generate first assembly?

I hope so, this was the way I was hoping Avid Script Sync would go.

[Premiopolis]

Trevor_Asq  wrote

So you are nearly able to take paper (word-processor) edit from transcripts & generate first assembly?

I hope so, this was the way I was hoping Avid Script Sync would go.

Answer to your question: An extremely optimistic... "maybe", even "probably"

There are a few quirks in the ExtendScript methods, noted here: https://forums.adobe.com/thread/2517330

but for rough assemblies it looks like this will work.  Adobe has the code!  BUT...

The reason for the "maybe": I haven't been able to test this fully in a production.

Why?  The producers -- a class of people that actually deserves to be discriminated against based on their existence.

Even though there's a clean and easy pipeline from transcript to script, where all the writer/producer has to do is copy from the transcript and paste to a the script -- a process which automatically carries the source clip name, Start & End TCs -- the diffident characters involved insist on erasing the End TC and even start TCs and sometimes even the clip names at random.  They actually go to extra effort to do that for no apparent reason and in a totally unaware manner.  So far efforts to dissuade them from doing this and making things unnecessarily difficult for themselves and others are met with a blank stare.

So ultimately the answer is: YES! This going to work.  But not until the current generation of producers retires.

Bruce Bullis: is there an ExtendScript command for activeProducer.remove();

[Bruce Bullis]

> is there an ExtendScript command for activeProducer.remove();

Not yet, and unlikely to be implemented, so long as those producers keep paying for their Creative Cloud subscriptions.

PEBKACs aside, the proximal difficulty is one of metadata plumbing.

In PPro, metadata is associated with a projectItem's actual media; that metadata is either injected into the asset (for most file types), or saved as a sidecar .xmp file, next to the asset (MXF files, some MPEG-1 variants.

The request to attach metadata to each CLIP in a sequence is problematic, in that clips (which the API calls 'trackItems') refer to the source projectItem, for associated metadata. From a trackItem, a script can access the static and temporal metadata associated with that trackItem's projectItem, but any metadata applied TO a trackItem is also thereby applied to every instance of the source projectItem.

However, based on my (limited) understanding of the use case, I think putting transcript text into clip markers, Might Work™.

[Premiopolis]

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

From a trackItem, a script can access the static and temporal metadata associated with that trackItem's projectItem, but any metadata applied TO a trackItem is also thereby applied to every instance of the source projectItem.

From ExtendScript's perspective, I understand.  But if you think about it from the UI perspective / PPro logic:

1 - A trackItem is likely be a unique entity with a UID.  In fact, if you copy SequenceA (and thereby all its track items) to SequenceB, that new sequence's trackItems are unique and separate from those in the original sequence, even if they initially are all the same.  In other words changing the properties of a trackItem in SequenceB (e.g. trimming, changing the opacity, applying motion and key frames etc etc) will not affect any trackItems of SequenceA.

(The exception Bruce refers to are things like adding a Marker to a source clip in a sequence.  In that case the Marker is applied not to the trackItem but to the projectItem.   In this example the Marker ends up appearing in all sequences that use the same projectItem at the same source TC.)

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

However, based on my (limited) understanding of the use case, I think putting transcript text into clip markers, Might Work™.

Adding script or transcript text to the sequence wan't exactly the goal.  The goal was to be able to insert a Reference ID into the trackItem -- or really any number of references which cross reference to datasets external to the PPro project.  The ExtendScript would handle the cross-referencing between sequence and any external datasets, and display the result in the panel.

The Marker approach doesn't really work for this.

1 - If you go with Sequence Markers, they don't link to trackItems. Even with "Ripple Sequence Markers" -- which kind of helps -- because they don't voyage with trackItem that is copy/pasted their value for this purpose falls apart.

2 - If you go with a trackItem Marker (i.e. a Marker applied to a trackItem in a sequence), that Marker, as noted above, actually affects the projectItem and affects all instances in all sequences, which undermines its use for doing the kind of Sequence-to-Script linking we're looking to build.

So the Marker approach doesn't really work for this purpose.

So a couple of concluding thoughts:

A - It should be possible to push values to a trackItem and not to a projectItem.  That's what Premiere is doing every time you do a trim: it sees, for instance, properties start, end, inPoint, and outPoint as variable properties it can change, and which are distinct to the trackItem, not the projectItem or its metadata.  That's not to say this is easy to code from Adobe's perspective, but technically it should be possible.

B - There is most likely a UID of some kind associated with each trackItem in every sequence.  Perusing the XML of the .prpoj file seemed to confirm this as well.  I would expect this UID is necessary for PPro to be able to do its job of tracking all the decisions editors make (i.e. the change they make all day long to the trackItems of their sequences).  If so, and if this UID were accessible to the ExtendScript API, that would be a breakthrough.  In the end, from my POV, it's not necessary to push any data into a trackItem.  It would be sufficient to have read-only access to a reliable trackItem UID and cross reference that back to whatever external data is being wrangled in the Custom HTML Panel.

I hope all that makes sense.  It's tough to communicate these tech things clearly.

[Bruce Bullis]

In other words changing the properties of a trackItem in SequenceB (e.g. trimming, changing the opacity, applying motion and key frames etc etc) will not affect any trackItems of SequenceA.

Yes, that's exactly the sort of behavior that's precluded, based on how metadata works across Adobe's apps.

I also agree that publishing a unique ID for each trackItem would allow panels to do all the heavy lifting, and seems much more likely to be implemented than "Add Yet Another Layer of project metadata handling, just in case someone wants to tag clips with stuff".

A - It should be possible to push values to a trackItem and not to a projectItem.

Broadly, I'd agree, and...

I once got castigated (in class) by my Epistemology professor, for using the word 'should'.

Professor Abraham: "Should? SHOULD, Mr. Bullis?! If you like using words like SHOULD, you should take a class in Moral Philosophy, not epistemology, because a word like SHOULD has ABSOLUTELY NO PLACE in a discussion based on logic and facts!!"

[dheidel]

This is an interesting conversation, one possible workaround to consider: ExtendScript can access and change effect properties of clips, and those effects live with the clip, not the projectItem. If you were able to develop or co-opt an effect that didn't change the image at all (perhaps the effect is disabled?), but just kept the metadata you needed in its parameters, you could probably get where you need to be.

See this conversation, that I've been following with interest, for information about how to  programmatically add an effect, albeit with the verboten QE dom.

This type of workflow could be made even more manageable if it was possible to access custom names that users have given effects or effect presets. Imagine if you co-opted the "Simple Text" effect to have your own metadata, but renamed the effect instance to something more meaningful (and easy for the panel to find in the event the user actually wanted a simple text effect on their clip as well) and saved that as an effect preset that could just be dropped on every clip. At least as of when I last checked, it's impossible to access that custom effect name (see question 2 in this unanswered thread​​, that's me from a different Creative Cloud account, btw), but that would make something like this much easier. It would also be great if Premiere offered an equivalent to the Expression Controls effects in After Effects for just this sort of workflow. The combination of an effect preset built using Expression Controls-like effects and a custom panel could be extremely potent for a number of different workflows!

[Premiopolis]

dheidel  wrote

ExtendScript can access and change effect properties of clips

See Scripting - Adding effects , that I've been following with interest, for information about how to  programmatically add an effect, albeit with the verboten QE dom.

"verboten"!! Thanks for the link and the idea.  Good one!!  Will test.

[Premiopolis]

dheidel   wrote

ExtendScript can access and change effect properties of clips

See Scripting - Adding effects  , that I've been following with interest, for information about how to  programmatically add an effect, albeit with the verboten QE dom.

Was able to get the Simple Text effect to work as a proxy for storing data: using the value of the text entry as a data field and the font size 0 or just turning it off.  The entry is readable & writable.  The whole approach is workable but ultimately ends up being a little kludgy: the fact of jerry rigging an effect is a little awkward in the first place.  Also the data entered reflects strangely when you actually turn the effect on and view it.  Not that it necessarily matters, but it doesn't immediately reflect on screen (you have to make some kind of manual change to the effect to wake it up to the programatic change), and it flickers with various unicode characters.   Wondering if that means there's something weird about the Simple Text effect? or maybe it expects to be set with extra control characters?  Are other effects as fickle when set programmatically?  Any, first attempt at this approach are a bit on the questionable side, but they could work.

[Trevor_Asq]

TC needs to be hidden in the script text somehow!

[Bruce Bullis]

Clip markers (markers associated with a given projectItem) have a start and end time...

[Trevor_Asq]

Like zero width unicode? — https://medium.com/@umpox/be-careful-what-you-copy-invisibly-inserting-usernames-into-text-with-zero...

[Premiopolis]

Trevor_Asq  wrote

Like zero width unicode? — https://medium.com/@umpox/be-careful-what-you-copy-invisibly-inserting-usernames-into-text -with-zer...

Could work.  Just tried an approach using trackItem.name

That seems like the most robust and effective workaround so far.

Bruce Bullis

I once got castigated (in class) by my Epistemology professor, for using the word 'should'.

Professor Abraham: "Should? SHOULD, Mr. Bullis?! If you like using words like SHOULD, you should take a class in Moral Philosophy, not epistemology, because a word like SHOULD has ABSOLUTELY NO PLACE in a discussion based on logic and facts!!"

JS is based on logic and, if not hard facts per se, at least hard definitions, and yet...

.1+.2==.3 //returns false.

It "shouldn't" but it does.

Take that, Abraham.