Premiere Pro 25 to 25.2 Beta ignores changes to PF_PUI_INVISIBLE for first instance of effect

[FxFactory]

Both release and beta versions of Premiere Pro 25 appear to have a regression whereby they ignore dynamic UI changes in the inspector for the very first instance of an effect, and only for the first instance used.

A quick recap: contrary to what happens in AE, the sanctioned way for third-party plugins to hide/show parameters in the inspector is to change the PF_PUI_INVISIBLE flag while handling 

PF_Cmd_UPDATE_PARAMS_UI or PF_Cmd_USER_CHANGED_PARAM. The docs also state that upon changing such a flag, plug-ins must call PF_UpdateParamUI() to notify Premiere that the parameter’s state in the inspector has changed. 

Now comes the interesting part: Premiere Pro ignores such changes for some parameters (there is variability to this) and only for the very first instance of the plugin. If you delete that first instance and apply more, the UI works just as expected. The attached screencast shows how to reliably reproduce this problem using one of our plugins. It’s unclear if the type of parameter (built-in vs custom) has any influence over the problem. In our experience, it helps to use a simple project (one clip on the timeline) on a cold start of the app with no existing plugins applied to the clip. There are other situations where this problem occurs – as our users have noticed – but the setup shown in the screencasts gives you 100% reproducibility so there’s little point in trying anything else.

Steps to reproduce:

- Install the most recent version of FxFactory (https://fxfactory.com/download/)

- Once FxFactory has been installed, launch the app and make sure FxFactory Pro is downloaded and installed.

- In Premiere, create a project with a single clip on the timeline and no plugins applied.

- Drag an instance of the FxFactory Pro Blur > Blur filter onto the clip.

- Make sure the inspector is showing parameters for the Blur filter.

- One such parameter is labeled Source. As you toggle between each icon in the row of icons displayed in the inspector, the appropriate parameters should become visible below it.

- By default, Source is set to ALL. Click on each icon in a sequence, and notice that no parameters become visible.

- Delete the instance of the Blur effect from the clip.

- Apply a new instance of Blur to the clip, and repeat the same process: click each icon displayed by the Source parameter. Notice that now, on this second instance of the effect, parameters do become visible or hidden dynamically, giving users the correct UI to configure the effect.

The above is the bare minimum to reproduce the issue. On that very first instance of the effect, the UI behaves even more oddly than described. If you keep playing with the Source parameter, some parameters will begin showing and hiding in unpredictable patterns... Premiere Pro appears to slowly "learn" that yes, it should start hiding and showing parameters... so as some users have noticed, the more you use the plugin, the more it "fixes itself" 🙂

Attached are two screencasts, one to show the "Steps to reproduce" in Premiere, and one to show how the first instance works just OK in AE. The latter is just for reference, AE gives plugins a very different mechanism to show/hide parameters dynamically.

[Bruce Bullis]

Great details, thanks Gabriele!

We're tracking this as DVARC-3737, and will keep you informed of our progress.

[Yanomanow]

@ Bruce Bullis, Thank you for considering this bug, it also affects our plugins !

Jean-MarcNoël - Yanobox

[omotion]

And our plugins are affected too.

Arturs 

omotion 

[FxFactory]

After further investigation, the only workaround for this issue appears to be avoiding the call to PF_UpdateParamUI() during PF_Cmd_USER_CHANGED_PARAM when running in Premiere Pro. This poses a problem, beyond the obvious fact that it contradicts the information in the SDK headers.

The reason a plugin needs to update parameter UI state during PF_Cmd_USER_CHANGED_PARAM is because it is responding to a specific user action, e.g. the user enables parameter A (e.g. "Blur Edges"), and the side effect is to make parameter B visible in the inspector (e.g. "Blur Radius"). In this scenario, the plugin can be efficient: asking the host to only change UI state for parameter B. It can be efficient because it knows that only parameters with a dependency on parameter A may need to be updated.

When a plugin is no longer allowed to change UI state during PF_Cmd_USER_CHANGED_PARAM, it is forced to do so during PF_Cmd_UPDATE_PARAMS_UI. And this implies it has to update all parameters. The "surgical" option is no longer on the table and therefore the plugin is forced to do a lot more work.

But even if this bug were fixed tomorrow (allowing plugins to call PF_UpdateParamUI() in Premiere Pro while handling PF_Cmd_USER_CHANGED_PARAM) this wouldn't be enough to solve the larger problem, due to another bug (yay). When the user changes a parameter’s value, plugins receive both PF_Cmd_USER_CHANGED_PARAM and PF_Cmd_UPDATE_PARAMS_UI. But, if the user chooses Edit > Undo, neither one of those messages are sent. Ideally, plugins should receive PF_Cmd_UPDATE_PARAMS_UI, and then have the option to request the second command by setting out_flags |= PF_OutFlag_REFRESH_UI. Instead, Premiere Pro is "optimizing" both commands away, and the UI is left in an inconsistent state because the plugin has no change to re-apply the correct parameter UI state.