Skip to main content
Bruce Bullis
Community Manager
Bruce BullisCommunity Manager
Community Manager
January 27, 2020
Answered

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

  • January 27, 2020
  • 4 replies
  • 10677 views

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!

 

    This topic has been closed for replies.
    Correct answer Bruce Bullis

    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?


    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%20Extension%20Cookbook.md

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

    4 replies

    joshuar83804708
    joshuar83804708
    Participating Frequently
    August 27, 2020

    I'm running the following code from visual studio debuger:

    ml = []

    alert(ml)

    this causes a  'Runtime Error: Error Code# 1: Illegal Parameter type @ file' error. is this because of the update? 

    '

      Tomas Sinkunas
      Tomas Sinkunas
      Legend
      August 28, 2020

      Yes, apparently New World will complain about _anything_ that's passed into alert() method if the argument is not of a String type. So alert(something.toString()) should work in theory, although it's far from being ideal when you need to alert() an array. For that, you would need to use alert(array.toSource()), unfortunately.

       

      And this is truly sad that you have to convert your arguments into strings to use them in an alert() method, as this is something you do not have to do in Javascript world.

        S
        Suancho
        Participant
        May 12, 2020

        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.

        Bruce Bullis
        Community Manager
        Bruce BullisCommunity ManagerAuthor
        Community Manager
        May 12, 2020

        As you've found, PPro 14.1 contains a QE DOM crasher. The problem is already fixed in PPro beta builds, and the fix will be present in PPro's next official release.

          S
          Suancho
          Participant
          May 12, 2020

          Thank you for your prompt reply!

          In the meantime, Is there any other way to apply audio or video effects?

          D
          dan.robo
          Participant
          May 1, 2020

          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-es-executescript/m-p/11067120?page=1

          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
          Community Manager
          Bruce BullisCommunity ManagerAuthor
          Community Manager
          May 1, 2020

          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
          Community Manager
          Bruce BullisCommunity ManagerAuthor
          Community Manager
          May 4, 2020

          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. 

            Premiopolis
            Premiopolis
            Inspiring
            March 6, 2020

            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
            Community Manager
            Bruce BullisCommunity ManagerAuthor
            Community Manager
            March 6, 2020

            In what hosts does the panel fail? 

            Did Chrome on that system, also update?

            Bruce Bullis
            Community Manager
            Bruce BullisCommunity ManagerAuthorCorrect answer
            Community Manager
            March 9, 2020

            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?


            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%20Extension%20Cookbook.md

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

            Terms & ConditionsAccessibility statement
            Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices