Crop: Rectangle filter's Corner Radius appears when only wanting to open Position/Size if a simple keyframe is set already

Bug
#1

I have set a simple keyframe beforehand and just want to open Position/Size parameter’s advanced keyframe view, but Corner Radius also shows up.
If no simple keyframe is set beforehand, this bug doesn’t occur.

Final
Final1200×850 137 KB

Steps to reproduce:

  1. Apply Crop: Rectangle to a clip.
  2. Set a simple keyfreame.
    This can be the first or second simple keyframe.
  3. Click the keyframe button for Position/Size parameter.
  4. Both paramters are opened in the keyframes dock.

Tested with v21.06.29.
Tested on Windows.

#2

I think this is normal and by design that switching from simple to advanced keyframes converts the simple keyframes for all parameters involved in simple. It does not check if there was a change in parameter value previously, while simple. Underneath, it’s all keyframes, and the UI simply switches modes. I have no plans to change this.

#3

But this behavior is inconsistent across filters. It’s even inconsistent within Crop: Rectangle.

Try the steps above again and click the keyframe button for Corner Radius in Step 3).
Only the Corner Radius keyframes show up, and Size/Position keyframes don’t show up.

Also try this with Size, Position and Rotation filter.

  1. Apply Size, Position and Rotation to a clip.
  2. Set a simple keyfreame.
  3. Click the keyframe button for Position & Size parameter.
  4. Only Position & Size keyframes show up, and the Rotation keyframes don’t show up.

As far as I know, Crop: Rectangle’s Position/Size keyframe button is the only instance that this occur.

#4

I think the correct response should be that all keyframable parameters should appear when switching from simple to advanced keyframes. I’ll put this on my todo list.

#5

Thinking some more about switching from simple to advanced keyframes, I think there are two options:

  1. Convert the simple keyframes to advanced keyframes.
  2. Clear all the simple keyframes in order to enable advanced keyframes. In this case, I would suggest to prompt/warn the user before clearing them

I am leaning slightly toward #2 because I think it would be easier to understand and support. Also, clearing the simple keyframes would be consistent with what we do in the other direction: when enabling simple keyframes any existing advanced keyframes are cleared.

Any suggestions on which would be better?

#6

The behavior of the other direction is necessary because the simple UI is less than the full/advanced UI. I prefer option 1 because you might set something up using simple keyframes and then decide to expand upon it with the full keyframes.

#7

I can support #1. Here is my suggestion for a comprehensive/consistent paradigm:

  1. When no keyframes are used and the user clicks any advanced keyframe button for a parameter

    • Automatically enable advanced keyframes for that parameter (current behavior)
    • Keyframe button for that parameter will be checked (current behavior)
    • No prompt to the user. (current behavior)

  2. When no keyframes are used and the user drags a simple keyframe handle

    • Automatically set “start”, “middle” and “end” simple keyframes for all parameters to the current value. (current behavior)
    • Keyframe button for all parameters will be unchecked (current behavior)
    • No prompt to the user. (current behavior)

  3. When simple keyframes are in use and the user clicks any advanced keyframe button for a parameter

    • Convert all simple keyframes for all parameters to advanced keyframes (current behavior is inconsistent)
    • Keyframe button for all parameters will be checked (current behavior is inconsistent)
    • Prompt the user before conversion with option to cancel (new behavior)

  4. When simple keyframes are in use and the user drags both simple keyframe handles to the edges (essentially disabling simple keyframes)

    • Remove all simple keyframes and set a single value for each parameter to the current value (current behavior is inconsistent)
    • Keyframe button for all parameters will be unchecked (current behavior)
    • Do not prompt the user (current behavior)

  5. When advanced keyframes are in use and the user toggles an advanced keyframe button

    • Disable all keyframes for that parameter and set the parameter to a single value that matches the current value (current behavior)
    • Keyframe button for that parameter will be unchecked (current behavior)
    • Prompt the user before deleting the keyframes and let them cancel if they want (current behavior)

  6. When advanced keyframes are in use and the user drags a simple keyframe handle

    • Clear all advanced keyframes (current behavior)
    • Keyframe button for all parameters will be unchecked (current behavior)
    • Prompt the user before conversion with option to cancel (new behavior)

I also propose to make simple keyframes “all or nothing” so that it is not possible to have some parameters using simple keyframes and some parameters using advanced keyframes. I audited all filters and there are not currently any filters with a “mix”. But the code is written to support this (isSimple is a member of each parameter). It would simplify the code and the UI concept if there are only three options:

  1. No keyframes
  2. All simple keyframes
  3. Advanced keyframes used on all or some parameters
#8

The 6 points listed above are implemented for the next release. I would appreciate some testing during the next beta phase in case any filters slipped through the cracks.