Functional usage of getLinkedItems method on a track item object

[andymees@aje]

Hi All

Am trying to get actionable "linked item" info from clips in an active sequence... what I mean by that is that on finding a clip (a track item) that has linked items (via clip.getLinkedItems) I'm trying to uniquely identify the correspondingly linked elements in the active sequence.'

As far as I can seem to tell tho, getLinkedItems just provides a regular track item collection object, with no objective reference as to 'where'in the active sequence those linked items are located (because there's no way to discern the track group, track no and/or clip no of each trackItem object contained). Am I understanding that correctly?

For example, if I have a clip with video on V1 and linked audio on A1 and A2 ... and I have a duplicate of that same clip on V2 with linked audio on A3 and A4 :

clipV1.getLinkedItems will return a collection with 1x clip-typeVideo object and 2x identical clip-typeAudio objects.

clipV2.getLinkedItems will return the same as the above ... as will clipA1/clipA2/clipA3 and ClipA4.getLinkedItems

... in that situation there would seem to be no way for me to identify directly (or even by inference) which clip elements are actually linked to each other.

So I'm thinking I may be using the wrong call to do what I'm trying to do... or maybe its the right call, but I'm using it in the wrong way? Or perhaps it's just not possible to do what I'm trying to do (other than by employing a 'best guess' logic) ... in which case, how is getLinkedItems intended to be used?

If anyone could shed a light it would be much appreciated. I'm learning as I go, including understanding both the power and the limitations of whats available for Premiere scripting.

Many thanks in advance.

Andy

[Bruce Bullis]

I'm confused; it seems like you're saying that clipV1.getLinkedItems() and clipV2.getLinkedItems() return correct results...?
More than 'linked', are you trying to determine clipV2's "ancestry" (from where it was duplicated)?

Could you describe the desired behavior, from the user's perspective?

[andymees@aje]

Hey Bruce

I think effectively what I'm saying is that a trackItem seems to have no unique identifier.

When stepping through a sequence programatically one can confer a unique identity to each trackItem by referencing the item's track group, track number and clip number ... but there is nothing within a trackItem itself that is necessarily unique.

As such, getLinkedItems() only tells me that the returned trackItems collectively make up all instances of a "linked clip" ... but that collection includes nothing that uniquely identifies where in the active sequence those clips are located. I can make a best guess by looking for any other trackItem that returns a matching "linked clip" collection ... but if duplicate linked items exist in the same sequence at the same start /end time (but on different tracks) then there seems to be no way for me to differentiate which items belong in which linked collection, as they will all appear to match.

I guess from a users perspective, the simplest behaviour would be for every trackItem to have it's own unique identifier property, regardless of links and/or ancestry. The function getLinkedItems() could then continue to work as is, but the unique identifier inherent in the trackItems returned would allow a user to discern specifically which trackItems belong in which linked group. Alternatively, a trackItem could include a trackNumber property. Again, getLinkedItems() could continue to work as is, but the track number property, together with the existing properties, would allow a user to discern the unique identity of each trackItem.

And another possibility is that I'm just missing something entirely obvious!

Cheers

Andy

[magarik]

I would also like that.

TrackItems have no id and no "track" property, no way to distinguish.