New World scripting will be ON by default, in next Premiere Pro release!

[Bruce Bullis]

As discussed on these forums and described in detail elsewhere, Premiere Pro is updating its internal script engine execution path. We're calling the existing ExtendScript engine, through the same new "plumbing" being used by the more modern JavaScript engine, which will be used by UXP. 

Our goal for this approach is that your existing ExtendScript code should continue to work, without modification, under New World scripting. New World has been available since Premiere Pro 13.1. Thank you to all our partners who've tested their scripts, and reported issues! 

 
We've fixed all known New World-related issues, for our forthcoming release.
 
The next release of Premiere Pro will default to New World. 

NOW would be a great time to test your PPro ExtendScript, to confirm that it's compatible with New World scripting. 🙂

 
Here's how to enable New World (don't do it before reading all instructions, below):
 

Display the Console using <ctrl>-<f12> (Win) or <cmd>-<f12> (MacOS X),  Use the 'hamburger' menu to set the view to Debug Database.

AME: set 'AME.ScriptLayer.EnableNewWorld' to true, to enable.
PPro and Prelude: set 'ScriptLayerPPro.EnableNewWorld' to true, to enable.

 
Here's how to test:
 
0. Install current version of PPro (and AME, if applicable). 
1. Launch host application.
2. Confirm via Console window's Debug Database (instructions above) that New World is NOT enabled.
3. Test your panel's ExtendScript. 
 
Interim result: Your ExtendScript should work as it normally does.
 
4. Enable NewWorld (via instructions above).
5. Close and re-launch PPro.
6. Confirm in Console that New World IS enabled.
7. Test your panel's ExtendScript functionality, again. 
 
Result: Does your panel's ExtendScript work correctly, with New World enabled? 
 
 
PLEASE let us know your results, using one of the following:
 
Yes!

No!

 

[Premiopolis]

Between yesterday and today our Adobe Panels stopped working.  Not sure if this is related, but we haven't been making changes to the panel on our end.  The only variable that I'm aware of is the Adobe App updates (Premiere and After Effects are both affected)

So far the only clue I've got comes from the Chrome debug, where I'm seeing the folllowing error in the console:

Uncaught TypeError: document.registerElement is not a function

at Object.UI.registerCustomElement (inspector.js:2964)
at inspector.js:2976

at inspector.js:2978

at inspector.js:2978

[Bruce Bullis]

In what hosts does the panel fail? 

Did Chrome on that system, also update?

[Premiopolis]

Ok, so the issues were twofold:

Part 1 - My mistake.  There actually had been a change on a server on my end I wasn't aware of, so addressing that was part of the solution.  My Adobe panels are back and up and running!

Part 2 - The inability to debug in the way I was used to does seem to have evaporated, killed somehow by the error posted above.  BUT over here on this forum page funkelodeon's post about chrome://inspect/#devices turned out to be a good fix, and possibly superior than the older method.

So on that front we're effectively OK, but there is still that error dangling out there.

Regarding your question: "In what hosts does the panel fail"

Answer: http://localhost:[port], with separate ports for PPro, AE, etc..  Both fail in the same way, with the same error listed above.

Question 1: My manifest.xml file still lists <RequiredRuntime Name="CSXS" Version="7.0" />.  Should that be versioned up?  What does it mean anyway?

Question 2: Also in manifest.xml, I've got <ExtensionManifest Version="6.0"  Should that be versioned up?  What does it mean anyway?

Question 3: I did version up CSinterface.js to v9.4.0.  Any juicy changes worth knowing about?  Do any other settings or setups need to be updated to accommodate that change?

[Bruce Bullis · Accepted solution]

What error, remains dangling? 

Question 1: That field specifies the version of CEP your panel uses. If your panel doesn't use any functionality/behavior specific to CEP9 or CEP8, then leaving it at 7.0 is fine.

Question 2: That specifies the version of the manifest definition. 

Question 3: If your panel is still specifying CSXS, then the host isn't providing it with CEP9 behaviors. And no, nothing particularly juicy; each CEP updates the version of Chromium in use. 

More information on manifests:
https://github.com/Adobe-CEP/CEP-Resources/blob/master/CEP_9.x/Documentation/CEP%209.0%20HTML%20Exte...

https://github.com/Adobe-CEP/CEP-Resources/blob/master/CEP_9.x/Documentation/CEP%209.0%20HTML%20Exte...

[Premiopolis]

Thanks for all that.  Lots to review in those links.

Re "What error, remains dangling?":

If we debug the way we used to, at http://localhost:[port] in Chrome, where the port number is defined for the specific app in the .debug file, this no longer works.  We get the error mentioned above, "Uncaught TypeError: document.registerElement is not a function" with no ability to debug.

Instead we're debugging by going to chrome://inspect/#devices in Chrome.

Is the older method of debugging outdated, or is there some config issue or other underlying problem we should be addressing?

[Bruce Bullis]

I think CEP will need to be updated, to re-enable the older debugging method.

[Premiopolis]

So I've been trying to figure out about upgrading to CEP9.  The links above have plenty of info -- notes about which apps are affected, deprecations in the API, even a promising header "Guide for migrating from CEP 7 to CEP 8", etc. but so far I didn't see any explainers on how to to actually upgrade.  Is it simply included as part of the Creative Cloud App update?

RE your note "If your panel is still specifying CSXS, then the host isn't providing it with CEP9 behaviors."

From what I can glean from this CEP9 Test extension, the key distinction in manifest.xml is still "CSXS" (as opposed to "CEP", with a change of version #, so  you'll see the follwing at line 30 of the test extension's manifest (<RequiredRuntime Name="CSXS" Version="9.0"/>)  I changed my manifest's "CSXS version" to 9.0 as well, tested the whole thing here and passed with flying colors, then re-signed the plug-in.  The plugin works fine, nothing different.  Am I CEP9?  or is there more to it?

If I am CEP9, great, but I'm still seeing the same error (Uncaught TypeError: document.registerElement is not a function) in the Chrome debugger at http://localhost:[port].

[Bruce Bullis]

Sorry, I was vague; I didn't mean you needed to update to a newer version of PPro; I meant CEP would need to update the version of Chromium it integrates, in order to address the debugging issue. 

> Am I CEP9?

Sounds like it; here's how to confirm.

https://github.com/Adobe-CEP/Samples/blob/1226dd14da66166f7d9a0a6cd2f0f44b8fe0ebda/PProPanel/ext.js#L9

[Premiopolis]

RE "Confirming CEP9 using csInterface.getCurrentApiVersion()": I get 9.0.4, which, if I'm not mistaken, is defined by choosing to include CSInterface.js (v9.0.4) in your plugin, correct?

RE "CEP would need to update the version of Chromium it integrates": How does that work?

[Bruce Bullis]

I'm surprised you didn't get 9.4.0...? 

> RE "CEP would need to update the version of Chromium it integrates": How does that work?

We would need to ship an updated version of PPro, containing an updated version of CEP. 

[Premiopolis]

> I'm surprised you didn't get 9.4.0...? 

Ugh.  Of course I did, but apparently I also had a brief bout of version dyslexia ®

> We would need to ship an updated version of PPro, containing an updated version of CEP. 

And that doesn't download via Creative Cloud updates?  Or does it?

BTW the whole reason I got into this was your Medium.com post about New World scripting, and the following lines in particular:

"You’re no longer required to pass control flow and information back and forth between JavaScript and ExtendScript layers, via string" -- meaning you can pass JSON directly?

"Your integration has access to the UI components used by the application" -- any more detail on this?

"scripting access to the UI components provided by the application" -- any more detail on this?

[Bruce Bullis]

> And that doesn't download via Creative Cloud updates?  Or does it?

There are no distinct CEP downloads; CEP is integrated into point products. Some happy day, a new version of PPro will contain a new version of CEP; that build of PPro will be available via Creative Cloud Desktop.

Another potential source of confusion; None of those quotes from my Medium post were about New World scripting; they all relate to UXP integration, which doesn't exist yet. 🙂

[Premiopolis]

> Some happy day, a new version of PPro will contain a new version of CEP;

Meaning for now the debug error I'm seeing in Chrome isn't fixable, correct?

If so, it's a nuisance but with a solution (chrome://inspect/#devices) that mostly out-performs the original.

> None of those quotes from my Medium post were about New World scripting; they all relate to UXP integration, which doesn't exist yet

Ok, standing by.  Sound cool.  Thx.

[Bruce Bullis]

> Meaning for now the debug error I'm seeing in Chrome isn't fixable, correct?

Niggling distinction: It's fixable, it's just not yet fixed. 

Yep, once UXP is available, we'll shout it from the rooftops. 🙂

[Premiopolis]

> once UXP is available, we'll shout it from the rooftops.

Is anyone running up to the roof by chance?

More generally, are any new developments the Adobe Extensions APIs? 

[Bruce Bullis]

No news on PPro UXP integration. 

[Premiopolis]

Are there any API developments of interest?  (or has COVID slowed dev process?)

If there are updates, is there a page that posts latest developments?  Always interested to see what you & team are up to.

[Bruce Bullis]

Nothing new to report. 🙂

[dan.robo]

I recently posted about getting crashes after upgrading to 14.0.3 when calling a old world simple script.

https://community.adobe.com/t5/adobe-media-encoder/ame-crash-introduced-in-14-0-3-when-using-console...

It looks like "AME.ScriptLayer.EnableNewWorld" is enabled by default now and AME just crashes when calling a old script.  @bbb_999 do you think this is something that will be resolved? Or will we have to disable NewWorld for our old scripts to work? 

[Bruce Bullis]

Hadn't seen that one!

We're tracking the issue as DVAME-4198702. Yes, for now, disabling New World makes the script run fine.

To disable: Open the Console (ctrl-F12 on Windows), and type the following in the text edit at the bottom:

debug.set AME.ScriptLayer.EnableNewWorld = false

[Bruce Bullis]

If you replace --executeScript (which expects a blob of ExtendScript to follow) with --executeFile (which expects a path to an ExtendScript file), the call works fine. 

[glendam87681220]

Thanks for the tip.  Is there any way to programmatically change the scripting engine without going into the console? 

I tested this but it doesn't work 

Adobe Media Encoder.exe --console debug.set AME.ScriptLayer.EnableNewWorld=false; es.executeFile "D:\TEST\test.jsx"

[Bruce Bullis]

In PPro yes, but not in AME. 

https://github.com/Adobe-CEP/Samples/blob/f86975c3689e29df03e7d815c3bb874045b7f991/PProPanel/jsx/PPR...

[Suancho]

I need help, please!

I can´t apply effects any more in Premiere. Methods like this: "qe.project.getActiveSequence().getAudioTrackAt(0);"

but with version 14 crashes every time. 

I think im already using New World.
Do you have an updated scripting guide?

Thanks in advance for your help.