When users change the value of a parameter declared by a plugin with the
PF_ParamFlag_SUPERVISE flag, the plugin ought to get notified via PF_Cmd_USER_CHANGED_PARAM. AE fails to do so when undoing the change. Plugins get PF_Cmd_USER_CHANGED_PARAM when the value is set, but not when the value is unset (via Undo).
(This bug affects both Premiere Pro and AE in almost identical fashion. They both fail to call PF_Cmd_USER_CHANGED_PARAM, but AE is at least calling PF_Cmd_UPDATE_PARAMS_UI while undoing the previous change.)
Steps to reproduce:
- Take an existing plug-in based on the AE SDK, and make one of its non-slider* parameters observable by setting its PF_ParamFlag_SUPERVISE flag.
- Set a breakpoint / print something to the console / beep when handling the PF_Cmd_USER_CHANGED_PARAM command.
- Apply the plugin inside AE.
- Change the observed parameter value and notice that Premiere will immediately invoke the PF_Cmd_USER_CHANGED_PARAM command.
- Select Edit > Undo and notice that no messages are sent to the plugin, which therefore has no chance of responding to the change.
* You cannot reproduce this bug with slider parameters because they are victim to another bug (a regression actually)... the PF_Cmd_USER_CHANGED_PARAM command is never invoked for sliders.
Expected:
Plug-ins should receive a PF_Cmd_USER_CHANGED_PARAM command regardless of how a parameter value has changed, directly or as a result of undoing a previous operation.
Notes:
Plugins rely on PF_Cmd_USER_CHANGED_PARAM to – among other things – change parameter UI state. E.g. if parameter A is toggled ON, the plug-in may choose to make a second parameter B visible in the inspector.
This bug means that when the user undoes a change, the parameter UI in the inspector can be left in an inconsistent state, with the wrong parameters visible/enabled.
1
Reply
AdChoices