2 Correct answers
It would seem you're going in through the UXP door.
Try the Developer Console: https://developer.adobe.com/console
I've confirmed with the Extensibility team that your road to publishing a CEP-based extension on the Adobe Exchange store, starts here.
https://partners.adobe.com/exchangeprogram/creativecloud
[It is not required that you publish your extension on our store]
18
Replies
Hi Bruce. Actually that is where I was asking this from... Is it correct you create a project and add a plug-in to it? I also saw the steps in the github page here: https://github.com/Adobe-CEP/Getting-Started-guides/tree/master/Package%20Distribute%20Install
I wasn't clear which is the path forward right now.
How do I register this ID with adobe?
<Extension Id="com.audiodesigndesk.ppro" Version="1.0.0"/>
For Premiere, are you still requiring the manual certificate signing as outlined here?
Well, I would say this system has some pretty large issues for someone walking into it cold.
I said “still" for a number of reasons. For one, I read this:
@ryan.f A few comments:
I often had to guess at errors as the debugger for vscode doesn’t have an arm64 Mac version, and it slows the editor down too much for me to use. I have an older M1 airbook. Bruce says the debugger works great fine for him in emulation, but it doesn’t for me. It’s unusable.
The ExtendScript Debugger extension for VS Code does work on Applie Silicon devices. I should know - I made it on one 😉.
The trick is that you need to run VS Code itself under emulation. This means that you have to right-click on the "Visual Studio Code.app" bundle (likely in your /Applications directory), select the "Get Info" option, and click "Open using Rosetta". (This is the workflow for Universal bundles of VS Code. You can alternatively download the Intel-specific version and not worry about this.)
Once you start VS Code after clicking that checkbox, then the ExtendScript Debugger extension will work fine.
That all said, the workflow is definitely subpar and I hope that @erinferinferinf is able to find the funding to update the extension to work with Apple Silicon devices natively.
If the above workflow doesn't work for you then that is a separate matter and likely indicates a bug somewhere or some other change that has entered into the picture. Narrowing that down if possible would be good.
Can you confirm that you have started VS Code in Rosetta (either with the checkbox I described above or by downloading and running the Intel-only version for macOS)?
@ryan.f wrote:And - that matches my impression of CEP exactly. It’s a very inefficient development environment, as least for how I normally work. Without any code completion, type checking, or modern tools, it’s slow.
Yes! More feedback like this, please! The more Adobe hears this from us users, the more likely they are to do something about it!
In your case, there are actually several options that will help you with Code Completion, Type Checking, and modern tooling. Specifically, see the following resources:
- Adobe-CEP/Samples/TypeScript - This is a sample that I put together years ago. It is unmaintained but it still shows one approach to setting up your environment to support adding type declarations for supporting both JavaScript and ExtendScript scripting contexts with Type Declaration file support (to power IntelliSense, Type Checking, etc.).
- Types-for-Adobe - This is a repository that contains [mostly] up-to-date type declaration files for ExtendScript APIs across Adobe's suite of CEP host applications. You can use that repository to source the core ExtendScript type declaration files and then the app-specific ones (i.e. Premiere Pro's). Or simply follow the directions in the repository... Manual control does require some knowledge about how TypeScript projects and type declaration resolution work.
@ryan.f wrote:Many things about this system are hidden in mystery. Bruce told me about the QE Dom but wouldn’t tell me what the calls are. So, in order to use it I had to walk the js document object for it to make my own documentation. Honestly, it would make more sense to just be clear as the information is publicly there - it just makes it tedious. Commit to an API or deprecate it - At least resolve the syntax differences in the qe vs app.
@Bruce Bullis can't tell you what the QE APIs are because they're intended for internal use only and any explicit mention of them may be interpreted as some as a form of "support" (i.e. "Bruce told me about that API and now it's gone! What the heck is that?!").
That said, this is where the community has your back. You're definitely not the first person to run into questions about the QE APIs. I myself cooked up some "documentation" for that hidden set of APIs and then shared it with the community (that's the link earlier in this paragraph). It doesn't have full documentation, but the doc is both searchable and can power autocompletion/IntelliSense/Type Checking in VS Code and other IDEs. So there's that.
Hopefully this is helpful to you. I also hope that your feedback here will be helpful for Adobe's UXP teams to better understand what sorts of documentation will be most helpful for empowering their users (us) to hit the ground running (type declarations for IDEs go a long, long way to helping us users...).
yeah sure - it runs in emulation - I tried rosetta vscode running the intel version as well as in emulation - but it doesn't run well. That was my point - I didn't mean to say it doesn't work at all.
I even ran it on my older intel mac, but that actually didn't feel all that much better to me. I need a snappy dev enviroment.
By @ryan.f
I mean... that sounds like it could be a bug. To be certain, you're running the latest version of the extension, yes? Currently that's v2.0.3.
The experience should be very peppy. It has been peppy on all macOS environments I've tested on (2018 Intel MBP and 2021 Apple Silicon MBP) and this is the first report I've heard of "it doesn't run well." While people did say that of v1.x, v2.x has been massively streamlined to run with almost little processing.
I would say "well, maybe Ryan is talking about the responsiveness of VS Code in Rosetta in general", but your statement that the Intel Mac you tested on had the same issue would discount that.
Would it be possible for you to do a quick screen recording (Quicktime makes this trivial) to show what you're describing? This might help us identify an issue that needs to be addressed (or otherwise point out some configuration issue you may be experiencing).
I don't wish to continue using CEP past what I need to do now, but the future uxp system looks promising - it's just not very nice to put a lot of effort into a deprecated system.
By @ryan.f
You will likely be using CEP for a while yet. Adobe has not announced any timeline for UXP adoption in the DVA apps (PPro, AE, Audition, etc.), though they do claim to be working on it. They have suggested that there will be a "bridge period" where both environments are supported for a while. It is likely that ExtendScript will survive in some capacity for at least a few more years.
I would like to point out that your feedback here is extra helpful, though. Adobe's type declaration efforts for UXP thus far have been... middling at best. I have recently been doing my utmost to convince them that providing declarations for users like you and I is of critical importance and should be a foundational element of the system/environment. It sounds like the teams are taking this to heart, but the more they hear things like:
It’s a very inefficient development environment, as least for how I normally work. Without any code completion, type checking, or modern tools, it’s slow.
(those features are enabled in IDEs by Type Declaration files), the better as it reinforces the ask!
At any rate, anything you can provide that shows the debugger extension behaving sluggishly would be very helpful.
AdChoices