PProHeadless executable embeds wrong/generic information in its serialized Info.plist

Fantastic! That is wonderful to hear!! When I still worked as an editor I used FXFactory every day. I had lots of fun with it! Cheers and happy holidays!!

This was immensely helpful. Had no idea that sending from AME vs Importing once you’re already in AME would trigger a different behavior that is conditional to that checkbox.

This explains a common source of confusion for our users. Why would plugins render via AME in some cases but not others? Now we know that sequences sent to AME likely always worked without issues, but any projects they were dragging/importing into AME were subject to failure (because our plugins woudn't recognize com.apple.product-type.tool as Premiere Pro). 

Today’s release of FxFactory (https://fxfactory.com/download/) should hopefully handle rendering via AME for both release and beta versions of Premiere Pro without issues. We'll need some time to review our codebase regarding the usefulness of a dedicated "host identification suite". With limited manpower available, there are outstanding issues that would be far more beneficial to our users (e.g. DVAAE-4226852). All in all, today Premiere Pro stands out as the best host app for plug-ins, among the four we focus on. On so many metrics it’s just wonderful.

In AME Preferences => General is a checkbox for "Import Sequences Natively" - when this is enabled you can either 'Send to AME' from PPro which opens the cloned sequence project in process (or not). You can also import the sequence(s) you want to render from a .prproj directly in AME as well.

I'll have to think about whether a whole new suite would make sense. I am very interested in testing PProHeadless on the latest beta. Under what circumstances does AME render a project directly within its own process, vs firing off PProHeadless? How does it make that decision, so I can test both paths?

Hi there - you're correct in that AEP/Comps are rendered for AME via aerendercore, PrProj/Sequences can be rendered either by AME in-process or via PProHeadless. The 'which version am I in' is a very reasonable feature to add, I'm thinking via a Suite rather than modifying entry points. What sort of info would you need to know to make decicions? Can follow up with a different discussion if needed.

Thanks Josh. I've just taken a very quick look at AME Beta 25 and it restores the behavior we had prior to Premiere Pro 25 (IIRC). From the point of view of our code, the host app that loads us is AME itself. It is no longer the PProHeadless process. 

Am I seeing this correctly? This was working great prior to 25, and should again be great when this fix is released, since we can make the assumption that the AME app only directly renders Premiere Pro projects whereas AE projects are funneled via aerendercore. I hope my understanding of this is correct, otherwise please enlighten me!

Hey there, I'm an adobe dev that works on some of this infrastructure code. 

We recently transitioned some of our build infrastructure and the CFBundleIdentifier was incorrectly being set to that generic string (overriding what it should be actually being set to, `com.adobe.PProHeadless.tool`). It functions as a command line tool, so we have chosen to differentiate it this way. Our current beta should reflect this and you should be able to look up the environment via this bundle identifier correctly. 

The bundle signature there is also incorrect, it should align with the main executable as well and we can update that to be the same as the top level executable as well. I totally agree that these plists settings should line up somewhat with the main app, and at least be something that makes sense! 

Hi Annika,

Thanks for looking into this so fast. Aside from the very specific perpective of plugins that rely on dynamic registration, the most obvious reason to address this problem has to do with how macOS works in general. The information in the Info.plist is vital in how system APIs identify your app uniquely on the system. Using generic placeholders is unlikely to be the correct approach. While you might be able to audit your source code to spot any such problematic spots, you don't have that option for third-party code, and you certainly wouldn't know if Apple is about to make an existing API suddenly require meaningful Info.plist entries to work correctly (think of ever-changing security policies, or how user consent for sensitive operations is recorded by the security layer.) So while you might legitimately choose a different set of values for the PProHeadless Info.plist, my guess is that you would still be better off avoiding the generic placeholders in place now. My vote is to choose something that "makes sense", i.e use the same version number as the Premiere Pro app, and use a bundle identifier that mirrors your existing convention, e.g. com.adobe.PremiereProHeadless.25, com.adobe.PremiereProBetaHeadless.25

Aside from that larger discussion, which Apple DTS would be more qualified to have, here are the specific reasons our software would be better off having those Info.plist values match the ones you are using for the main Premiere Pro app:

- We use dynamic plugin registration exclusively, ever since this has worked reliably for both software and GPU accelerated effects in Premiere Pro (IIRC that was version 22).

- Our software makes a number of decisions early on. Should or should I not load this product/plugin? Should or should I not install these additional assets (e.g. Fonts)? There is no point wasting time and memory loading and advertising plugins and copying/registering files that aren't supported by your app. App launch times would suffer for no good reason.

- When decisions are made by our software, the Info.plist values accessible through NSBundle are the only reliable way to know what app and version is loading our software. In an ideal world, every single entry point from your apps into our software would provide this info, but this is trivially not the case. Some entry points don't identify app or version (e.g. xImportEntry). The PluginDataEntryFunction we use for dynamic registration does provide app and version, but it does not seem to be invoked by PProHeadless. In light of the fact that the timing these entry points are invoked is entirely up to your app, and has changed over the years (with some regressions along the way) identifying the host app info through its bundle has been the only reliable mechanism so far. 

If and until you decide to address this problem in PProHeadless, the only workaround I have come up with is to recognize the generic placeholder (com.apple.product-type.tool), work my way in the filesystem to locate the parent app’s (Premiere Pro) Info.plist, and read those values directly. But this feels very weak, as it still leaves the question as to which macOS APIs we are using that have a chance of failure due to the lack of appropriate Info.plist values. 

Hi there! We'd need need a bit more context what keys you are trying to access and how? How are you determining what process you are running in and what key are you expecting? What are you trying to achieve by accessing the CFBundleIdentifier? Thanks!