Sure. And ultimately this is a question about convenience, not functionality
If we've lost the ability run scripts directly from the IDE and also lost the ability to trigger JSX files to run via CLI, it's hardly the end of the world. We'll just build the equivalent.
So maybe the question is: can I be lazy and not have to build those functionalities or are they still available in the new VSCode context? And it seems the answer is no.
Lazy only lasts so long. I was never crazy about ExtendScript as an IDE, nor the security pop-up when using the CLI call. But as long as they were available and workable enough, we were using them and not building the more robust systems I would have preferred. Now I'm a little more motivated.
If use cases are at all helpful: one of the reasons I prefer to have the option to trigger ExtendScript procedures outside of Premiere has everything to do with PPro's long-standing non-responsiveness to complaints that Smart Bin and Project Filter functions are unreliable. There are tons of feature requests and forums postings about it, going on for years now. At this point rather than fight it, we just build solutions to make up for it.
The need to fluently navigate footage in professional work environments, where you're regularly wrangling 10,000 assets or more. Asset management, searchability -- finding footage you want when you want as fluently as possible, is one of the key ingredients to pushing new boundaries in post. Adobe has all the potential to far outperform even Avid, which makes minimal use of metadata. Adobe, by contrast, has this massive architecture around metadata and yet makes a bare minimum of use of it when it comes to project filtering and smart bins. And even that bare minimum tends to work fleetingly and unreliably.
To the rescue Bruce Bullis and the team handling ExtendScript. We do all the asset and metadata management in databases external to Adobe, where we can generate, maintain, update, and search with greater speed, articulation and customization than we can currently wrangle out of un-customized PPro. Sometimes we make those features available in a panel. But frequently (for lack of time, deadlines, or laziness) it's easier to search the external database and push ExtendScript code externally. In other words the ability to run ExtendScript within a panel or external to it, is a decision we're making all day every day.
This is less a lament about the loss of some functionality -- that's just a minor inconvenience and an overdue kick in the pants to do some coding we've been meaning to get to -- than an attempt to communicate how much I and by extension the various teams I work with value the ability to extend PPro's core functionality with customized code. We sometimes develop apps for paying clients, but more often than not we're custom coding whatever we need as fast as we can to meet the unique and idiosyncratic needs of the projects we're currently working on. We're editors who lust for code as opposed to developers hocking code to editors.
Hopefully this makes sense over at Team Adobe. Big fans here, but pushing for more.
4
Replies
AdChoices