Finding a bin with Project.findItemsMatchingMediaPath()?

[sberic]

I'm trying to figure out how to locate a known bin by name. I see that there's a Project.findItemsMatchingMediaPath() API. I've been able to use it to locate Clips but attempts to locate Bins have been unsuccessful.

What's the expected way for us to traverse the bin hierarchy? What's the best way to locate a specific bin within the project?

[andymees@aje]

Hey sberic, there's a function in Bruce's PProPanel Premiere.jsx script that specifically addresses this : searchForBinWithName

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

[sberic]

andymees@aje​ wrote

Hey sberic , there's a function in Bruce's PProPanel Premiere.jsx script that specifically addresses this : searchForBinWithName

Thanks for the pointer, andymees@aje​​. Unfortunately, that code only partially solves the problem. The function would be more aptly named "searchForBinWithNameInProjectRoot". It does not help if you have a path that goes beyond the root bin.

e.d. wrote

You can either do it as andymees@aje has suggested for an iterative "drill down" seach, or if you have a projectItem, use its treePath property for "bubble up" search (split by slashes, array length will help you figure out the "level"...)

The drill-down search I understand. It was our original approach until findItemsMatchingMediaPath() got our hopes up. I don't follow what you mean with the "bubble up", though. I guess you mean that you could iteratively search the children of each bin in the path, enabling a directed search, rather than a standard depth or breadth-first search?

e.d. wrote

Bins don't have a media path, they're just hierarchy objects (with projectItemType = 2).

Gotcha. That's a bit unfortunate. It feels very similar to file/directory traversal. Seems like some documentation for the findItemsMatchingMediaPath() is in order; some that includes the restrictions on how it may be used.

I guess I'd like to eventually see an API like findItemsMatchingPath() be added to stop us all from having to write the same "digging down" code.

[e_d_]

sberic  schrieb

Thanks for the pointer, andymees@aje . Unfortunately, that code only partially solves the problem. The function would be more aptly named "searchForBinWithNameInProjectRoot". It does not help if you have a path that goes beyond the root bin.

Oh you're referring to Line#188, I was thinking in terms of Line#835, and to modify/combine this with the former. Should be doable.

The drill-down search I understand. It was our original approach until findItemsMatchingMediaPath() got our hopes up. I don't follow what you mean with the "bubble up", though. I guess you mean that you could iteratively search the children of each bin in the path, enabling a directed search, rather than a standard depth or breadth-first search?

I meant to say should you already have a (reference to a) projectItem as a result of a previous query/process/whatever, this would also give you a reference to its bin "position", right?

[andymees@aje]

Unfortunately, that code only partially solves the problem. The function would be more aptly named "searchForBinWithNameInProjectRoot". It does not help if you have a path that goes beyond the root bin.

You're absolutely right ... I assumed it was recursive without actually checking. Apologies for the misdirection.

[sberic]

andymees@aje​ No worries! Thanks for the help, regardless!

e.d. wrote

Oh you're referring to Line#188, I was thinking in terms of Line#835, and to modify/combine this with the former. Should be doable.

Oh, I missed that one. That is definitely a more thorough approach.

That said, is it just me or is that thing buggy? Two points:

1. The first recursive call starts looking at bins in the next layer at a position based on the parent layers' index??
2. Why are we checking against the next child in the list​ manually? Isn't that what would happen automatically by simply falling through to the next iteration of the loop?

I mean, shouldn't that entire function look like this:

searchBinForProjItemByName : function(i, currentItem, nameToFind){
    for (var j = i; j < currentItem.children.numItems; j++){
        var currentChild = currentItem.children;
        if (currentChild.type == ProjectItemType.BIN){
            return $._PPP_.searchBinForProjItemByName(0, currentChild, nameToFind);
        } else if (currentChild.name == nameToFind){
            return currentChild;
        }
    }
}

Much simpler and makes fewer checks. Bruce Bullis​? Any insight into this? Is there a reason for things to be written as they are?

e.d. wrote

I meant to say should you already have a (reference to a) projectItem as a result of a previous query/process/whatever, this would also give you a reference to its bin "position", right?

Not necessarily, no. What if I'm looking to add an item to a bin with a special name? It might be something I've hard-coded to a location. It might also be something that the user should be able to organize as they like (although not rename as we cannot associate any special hidden metadata to a bin). In one case I know the bin path but then have to do a search anyway as the only way to drill down is to iterate over all items until you find what you're looking for. (This is likely how it would be internally anyway, but at least we all wouldn't have to code the same thing ;D)

[e_d_ · Accepted solution]

You can either do it as andymees@aje​ has suggested for an iterative "drill down" seach, or if you have a projectItem, use its treePath property for "bubble up" search (split by slashes, array length will help you figure out the "level"...)

Bins don't have a media path, they're just hierarchy objects (with projectItemType = 2).