VSE Retiming Functionality #112343

New Issue

Open

opened 2023-09-13 18:26:52 +02:00 by Francesco Siddi · 18 comments

Francesco Siddi commented 2023-09-13 18:26:52 +02:00

Member

Copy Link

This design describes the VSE strip retiming functionality. The goal of the feature set is to allow intuitive and flexible retiming of video, audio, scene and meta strips.

It’s possible to adjust the “speed” of one or multiple strips in a few ways. In the context of the Sequencer editor, in timeline view:

• Select one or multiple strips, open the Strip menu, and choose Retiming->Set speed. This allows to input an arbitrary speed percentage for the entire strip.
• Select one or multiple strips, press the “R” key (or choose Strip->Retiming->Display Retiming Keys), which will display the retiming keys overlaid on the strips.
  • At this point it’s possible to select one or more keys and transform them to change the speed of a strip.
  • Because both strips and keys can be selected and transformed, we determine what entity should be transformable based on the last selection. For example, when selecting a key, all other keys are selectable and transformable. When selecting a strip, all other strips are selectable and transformable.
  • When a strip is selected, pressing the I key, displays a menu to insert a retiming key or a freeze frame key
  • Editing (transform, delete…) operations on keys should work similar to any other animation editor

Here is greyscale wireframe of how retiming keys relate to Sequencer strips.

This design describes the VSE strip retiming functionality. The goal of the feature set is to allow intuitive and flexible retiming of video, audio, scene and meta strips. It’s possible to adjust the “speed” of one or multiple strips in a few ways. In the context of the Sequencer editor, in timeline view: * Select one or multiple strips, open the Strip menu, and choose Retiming->Set speed. This allows to input an arbitrary speed percentage for the entire strip. * Select one or multiple strips, press the “R” key (or choose Strip->Retiming->Display Retiming Keys), which will display the retiming keys overlaid on the strips. * At this point it’s possible to select one or more keys and transform them to change the speed of a strip. * Because both strips and keys can be selected and transformed, we determine what entity should be transformable based on the last selection. For example, when selecting a key, all other keys are selectable and transformable. When selecting a strip, all other strips are selectable and transformable. * When a strip is selected, pressing the I key, displays a menu to insert a retiming key or a freeze frame key * Editing (transform, delete…) operations on keys should work similar to any other animation editor Here is greyscale wireframe of how retiming keys relate to Sequencer strips. 

Pasted Graphic.png

67 KiB

Francesco Siddi added the

Type

Design

label 2023-09-13 18:26:52 +02:00

Francesco Siddi added this to the Video Sequencer project 2023-09-13 18:27:04 +02:00

Francesco Siddi added the

Module

VFX & Video

Interest

Video Sequencer

labels 2023-09-13 18:27:22 +02:00

Francesco Siddi referenced this issue 2023-09-13 18:33:13 +02:00

VSE: Improve retiming UI #109044

Nika Kutsniashvili commented 2023-09-13 23:54:20 +02:00

Contributor

Copy Link

Is tool being removed for in favor of operator?

Is tool being removed for in favor of operator?

Francesco Siddi commented 2023-09-14 00:02:13 +02:00

Author

Member

Copy Link

The tool, as it currently works, is being removed. The behavior described in in this design is closer to what you would expect from a mode. A tool that allows retiming a strip by resizing its ends can be reintroduced later.

The tool, as it currently works, is being removed. The behavior described in in this design is closer to what you would expect from a mode. A tool that allows retiming a strip by resizing its ends can be reintroduced later.

tintwotin commented 2023-09-16 15:43:09 +02:00

Copy Link

There are several things in this design which seems to me to break UX consistency of Blender:

Select one or multiple strips, open the Strip menu, and choose Retiming->Set speed. This allows to input an arbitrary speed percentage for the entire strip.

When changing strip properties, it is done in the Sidebar.

Select one or multiple strips, press the “R” key (or choose Strip->Retiming->Display Retiming Keys), which will display the retiming keys overlaid on the strips.

Is it like an overlay/display switch, but with interactivity included? Should it only work for the selected strips or for all strips? Do you need to switch it off again? If they shouldn't be switched off again, working with very small strips and accidentally moving keys instead of strip or handle will become a common annoyance. Or is this actually modal editing, which normally is either initiated by selecting a tool or in modes ex. Object/Edit etc. mode?

Because both strips and keys can be selected and transformed, we determine what entity should be transformable based on the last selection. For example, when selecting a key, all other keys are selectable and transformable. When selecting a strip, all other strips are selectable and transformable.

This seems to be very non-Blender-ish concept, changing editing mode via the last selection? This is bound to confuse users, and it basically means that you can't click and hold to drag ex. a key around, like you normally can with keys, but instead you'll have to click twice on a key in order to move a key. So half of the time, going between editing modes, users will think that selecting is unresponsive and failing. This is going to lead to a lot of frustrations.

Also, adding the displaying of keys to the bottom of the strip, will make it collide with trim numbers, and in the case of the first channel, collide with the markers area, as mentioned here: #109044 (comment) and here: #109044 (comment)

There are several things in this design which seems to me to break UX consistency of Blender: > Select one or multiple strips, open the Strip menu, and choose Retiming->Set speed. This allows to input an arbitrary speed percentage for the entire strip. When changing strip properties, it is done in the Sidebar. > Select one or multiple strips, press the “R” key (or choose Strip->Retiming->Display Retiming Keys), which will display the retiming keys overlaid on the strips. Is it like an overlay/display switch, but with interactivity included? Should it only work for the selected strips or for all strips? Do you need to switch it off again? If they shouldn't be switched off again, working with very small strips and accidentally moving keys instead of strip or handle will become a common annoyance. Or is this actually modal editing, which normally is either initiated by selecting a tool or in modes ex. Object/Edit etc. mode? > Because both strips and keys can be selected and transformed, we determine what entity should be transformable based on the last selection. For example, when selecting a key, all other keys are selectable and transformable. When selecting a strip, all other strips are selectable and transformable. This seems to be very non-Blender-ish concept, changing editing mode via the last selection? This is bound to confuse users, and it basically means that you can't click and hold to drag ex. a key around, like you normally can with keys, but instead you'll have to click twice on a key in order to move a key. So half of the time, going between editing modes, users will think that selecting is unresponsive and failing. This is going to lead to a lot of frustrations. Also, adding the displaying of keys to the bottom of the strip, will make it collide with trim numbers, and in the case of the first channel, collide with the markers area, as mentioned here: https://projects.blender.org/blender/blender/pulls/109044#issuecomment-1005785 and here: https://projects.blender.org/blender/blender/pulls/109044#issuecomment-990923

Francesco Siddi commented 2023-09-16 18:07:45 +02:00

Author

Member

Copy Link

When changing strip properties, it is done in the Sidebar.

Speed it not a value. It can be described more as a function. An interesting way to represent a strip wold with an f-curve widget, but that wold come with its own challenges, since a strip can be trimmed as well and the time mapping would still not be obvious.

Or is this actually modal editing, which normally is either initiated by selecting a tool or in modes ex. Object/Edit etc. mode?

It's not exactly modal editing, although it wold be something worth exploring when looking into future, more complex functionality to be attached to strips in the timeline itself.

The concept of "mode switching" based on last selection is a bit obscure but not new in Blender (weight painting/bone selection).

From the issues you reported I believe you have been testing this, so I'd like to hear if you have suggestions on how the interaction could be improved.

About the issues themselves, they are valid, and value labels should not overlap anywhere.

> When changing strip properties, it is done in the Sidebar. Speed it not a value. It can be described more as a function. An interesting way to represent a strip wold with an f-curve widget, but that wold come with its own challenges, since a strip can be trimmed as well and the time mapping would still not be obvious. > Or is this actually modal editing, which normally is either initiated by selecting a tool or in modes ex. Object/Edit etc. mode? It's not exactly modal editing, although it wold be something worth exploring when looking into future, more complex functionality to be attached to strips in the timeline itself. The concept of "mode switching" based on last selection is a bit obscure but not new in Blender (weight painting/bone selection). From the issues you reported I believe you have been testing this, so I'd like to hear if you have suggestions on how the interaction could be improved. About the issues themselves, they are valid, and value labels should not overlap anywhere.

tintwotin commented 2023-09-18 10:19:42 +02:00

Copy Link

I wonder what the thoughts have been behind this process. Originally, the Retime function was implemented as a tool and widget based solution completely independent of the current keying systems. Though a lot of the functionality mirrors key functionality. Visually, it was implemented as markers. Then menus were introduced and exposed in the main menus and now the tool functionality is removed and several solutions breaking intuitiveness and UX is introduced.

If you're asking me, the speed value should just have been a keyable value working on top of the display frame value, and it should have been exposed on the strips as any other keyable value in the VSE. Or in other words a working visual solution for all keyable values should have been found(look at the NLA). And then implement a keyframe editor tool to display and interact with those keys. If you both want a one speed arbitrary value and a keyframeable solution, users should be able to switch between them in the Strip properties sidebar enum/radio button, so only one of them had power over the strip.

But it doesn't matter what I think. In the current situation, ISS has already proved that the hard part of proper retiming can and is done. So, I would really, really recommend, that all of you to sit down with the UI team and find a durable and intuitive working solution, before more time is wasted on implementing yet another less than optimal solution.

On a different note:

Speed it not a value. It can be described more as a function. An interesting way to represent a strip wold with an f-curve widget, but that wold come with its own challenges, since a strip can be trimmed as well and the time mapping would still not be obvious.

If you want to see the resulting frame drawn as f-curve on the strip:
https://archive.blender.org/developer/file/10365/10365519/0001-1578.mp4
https://archive.blender.org/developer/differential/0012/0012386/index.html

I wonder what the thoughts have been behind this process. Originally, the Retime function was implemented as a tool and widget based solution completely independent of the current keying systems. Though a lot of the functionality mirrors key functionality. Visually, it was implemented as markers. Then menus were introduced and exposed in the main menus and now the tool functionality is removed and several solutions breaking intuitiveness and UX is introduced. If you're asking me, the speed value should just have been a keyable value working on top of the display frame value, and it should have been exposed on the strips as any other keyable value in the VSE. Or in other words a working visual solution for all keyable values should have been found(look at the NLA). And then implement a keyframe editor tool to display and interact with those keys. If you both want a one speed arbitrary value and a keyframeable solution, users should be able to switch between them in the Strip properties sidebar enum/radio button, so only one of them had power over the strip. But it doesn't matter what I think. In the current situation, ISS has already proved that the hard part of proper retiming can and is done. So, I would really, really recommend, that all of you to sit down with the UI team and find a durable and intuitive working solution, before more time is wasted on implementing yet another less than optimal solution. On a different note: > Speed it not a value. It can be described more as a function. An interesting way to represent a strip wold with an f-curve widget, but that wold come with its own challenges, since a strip can be trimmed as well and the time mapping would still not be obvious. If you want to see the resulting frame drawn as f-curve on the strip: https://archive.blender.org/developer/file/10365/10365519/0001-1578.mp4 https://archive.blender.org/developer/differential/0012/0012386/index.html

Francesco Siddi commented 2023-09-21 01:49:58 +02:00

Author

Member

Copy Link

Thanks for the feedback. The current design is being tested with Pablo and others at Blender Studio. While the current solution is relatively simple and limited to managing "speed", the ability to display and animate other attributes (as you suggest) is being kept in mind.

Thanks for the feedback. The current design is being tested with Pablo and others at Blender Studio. While the current solution is relatively simple and limited to managing "speed", the ability to display and animate other attributes (as you suggest) is being kept in mind.

Julien Kaspar commented 2023-09-29 18:27:07 +02:00

Member

Copy Link

I just started testing the current implementation. Here are various notes. Would be great to talk more in detail about these.

Retiming Toggle

• Ctrl R is not a good shortcut choice imo. It is a very established and frequently used shortcut for Refreshing. It's fair to say that Blender shouldn't need this shortcut,for now it is still absolutely required. Once it is made obsolete we can think about replacing/removing it.
• Toggling Retiming has a misleading name. It's toggling the editing, not the retiming. Maybe instead name it "Retime Editing"
• The toggle should be exposed somewhere clearly visible too instead of a only in a nested menu. Ideally directly on the strip. This needs a design sure.

Transforming Keys

• Moving keys does not move all keys further to the right. But that is the more desireable default behavior for the majority of the time when working with retiming because otherwise you are editing more than just the timing of the key you've selected.

  • I propose a better mental model for the keys: Treat keys as the starting point of a block. A "retiming section with a start & an end"
  • If a key is selected and transformed, ONLY the related retiming section is edited
  • If multiple keys are selected, EACH of the affected retiming section is edited

• I could see multiple ways to implement this

  • Use G to do the behavior I described above and another shortcut and operator to do the current behavior.
  • Use something like Modifier Key + Select to select the key and all keys to the right before editing
  • Introduce a toggle to change the behavior and visual representation between keys and boxes

Retiming Menu

• The menu has entries that disappear unless a retiming key is selected. These should be greyed out instead with tooltip hints on when they are available
• Set Speed doesn't do anything to selected keys. Unclear if it only applies to the base speed of the strip???
• Deselect All doesn't have a shortcut shown in the menu even though it's Alt A

Speed Transitions

• Keys that have a speed transition still can't be moved. The speed transition can only be scaled
• No way to remove speed transition. Should be in the context menu as well

Retiming Overlay

• The retiming overlay is still visible when disabled until all retiming keys have been deselected.

Scalable design

• The UI of showing keys as keyframes on the strip is great. How will this scale if more animated properties can be displayed this way?

I just started testing the current implementation. Here are various notes. Would be great to talk more in detail about these. ## Retiming Toggle - **`Ctrl R`** is not a good shortcut choice imo. It is a very established and frequently used shortcut for Refreshing. It's fair to say that Blender shouldn't need this shortcut,for now it is still absolutely required. Once it is made obsolete we can think about replacing/removing it. - Toggling Retiming has a misleading name. It's toggling the editing, not the retiming. Maybe instead name it "Retime Editing" - The toggle should be exposed somewhere clearly visible too instead of a only in a nested menu. Ideally directly on the strip. This needs a design sure. ## Transforming Keys - Moving keys does not move all keys further to the right. But that is the more desireable default behavior for the majority of the time when working with retiming because otherwise you are editing more than just the timing of the key you've selected. - I propose a better mental model for the keys: Treat **keys** as the starting point of a block. A "**retiming section** with a start & an end" - If a key is selected and transformed, **ONLY** the related retiming section is edited - If multiple keys are selected, **EACH** of the affected retiming section is edited - I could see multiple ways to implement this - Use **`G`** to do the behavior I described above and another shortcut and operator to do the current behavior. - Use something like `Modifier Key + Select` to select the key and all keys to the right before editing - Introduce a toggle to change the behavior and visual representation between keys and [boxes](https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/#reworked-timeline) ## Retiming Menu - The menu has entries that disappear unless a retiming key is selected. These should be greyed out instead with tooltip hints on when they are available - Set Speed doesn't do anything to selected keys. Unclear if it only applies to the base speed of the strip??? - Deselect All doesn't have a shortcut shown in the menu even though it's **`Alt A`** ## Speed Transitions - Keys that have a speed transition still can't be moved. The speed transition can only be scaled - No way to remove speed transition. Should be in the context menu as well ## Retiming Overlay - The retiming overlay is still visible when disabled until all retiming keys have been deselected. ## Scalable design - The UI of showing keys as keyframes on the strip is great. How will this scale if more animated properties can be displayed this way?

Francesco Siddi commented 2023-09-29 19:09:38 +02:00

Author

Member

Copy Link

Retiming Toggle

• Ctrl R is not a good shortcut choice imo. It is a very established and frequently used shortcut for Refreshing. It's fair to say that Blender shouldn't need this shortcut,for now it is still absolutely required. Once it is made obsolete we can think about replacing/removing it.

This should be obsolete already. If there are situation where Ctrl+R is still required, they should be reported and fixed.

• Toggling Retiming has a misleading name. It's toggling the editing, not the retiming. Maybe instead name it "Retime Editing"

The suggested name should be "Toggle Retiming Keys"

• The toggle should be exposed somewhere clearly visible too instead of a only in a nested menu. Ideally directly on the strip. This needs a design sure.

As long as there is a keyboard shortcut, having logical nesting does not seem to be a problem. The context for that command is "Retiming", and that's what we have as top level menu.

Transforming Keys

• Moving keys does not move all keys further to the right. But that is the more desireable default behavior for the majority of the time when working with retiming because otherwise you are editing more than just the timing of the key you've selected.

  • I propose a better mental model for the keys: Treat keys as the starting point of a block. A "retiming section with a start & an end"
  • If a key is selected and transformed, ONLY the related retiming section is edited
  • If multiple keys are selected, EACH of the affected retiming section is edited

• I could see multiple ways to implement this

  • Use G to do the behavior I described above and another shortcut and operator to do the current behavior.
  • Use something like Modifier Key + Select to select the key and all keys to the right before editing
  • Introduce a toggle to change the behavior and visual representation between keys and boxes

The current design follows all the other keyframe editors. Ctrl+Click (left or right of the playhead) should be the selector for all keys in a strip. I understand the desire for a more bespoke behavior, but I'd fully make sure the "default" behavior is implemented first. Having an easy way to translate proportionally all keys is a very valid feature, especially when working with large strips.

Scalable design

• The UI of showing keys as keyframes on the strip is great. How will this scale if more animated properties can be displayed this way?

There are thought about this, but no published design. It's on my todo list.

> ## Retiming Toggle > - **`Ctrl R`** is not a good shortcut choice imo. It is a very established and frequently used shortcut for Refreshing. It's fair to say that Blender shouldn't need this shortcut,for now it is still absolutely required. Once it is made obsolete we can think about replacing/removing it. This should be obsolete already. If there are situation where Ctrl+R is still required, they should be reported and fixed. > - Toggling Retiming has a misleading name. It's toggling the editing, not the retiming. Maybe instead name it "Retime Editing" The suggested name should be "Toggle Retiming Keys" > - The toggle should be exposed somewhere clearly visible too instead of a only in a nested menu. Ideally directly on the strip. This needs a design sure. As long as there is a keyboard shortcut, having logical nesting does not seem to be a problem. The context for that command is "Retiming", and that's what we have as top level menu. > > ## Transforming Keys > - Moving keys does not move all keys further to the right. But that is the more desireable default behavior for the majority of the time when working with retiming because otherwise you are editing more than just the timing of the key you've selected. > - I propose a better mental model for the keys: Treat **keys** as the starting point of a block. A "**retiming section** with a start & an end" > - If a key is selected and transformed, **ONLY** the related retiming section is edited > - If multiple keys are selected, **EACH** of the affected retiming section is edited > > - I could see multiple ways to implement this > - Use **`G`** to do the behavior I described above and another shortcut and operator to do the current behavior. > - Use something like `Modifier Key + Select` to select the key and all keys to the right before editing > - Introduce a toggle to change the behavior and visual representation between keys and [boxes](https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/#reworked-timeline) > The current design follows all the other keyframe editors. Ctrl+Click (left or right of the playhead) should be the selector for all keys in a strip. I understand the desire for a more bespoke behavior, but I'd fully make sure the "default" behavior is implemented first. Having an easy way to translate proportionally all keys is a very valid feature, especially when working with large strips. > ## Scalable design > - The UI of showing keys as keyframes on the strip is great. How will this scale if more animated properties can be displayed this way? There are thought about this, but no published design. It's on my todo list.

👍 1

Julien Kaspar commented 2023-09-30 00:32:14 +02:00

Member

Copy Link

As long as there is a keyboard shortcut, having logical nesting does not seem to be a problem. The context for that command is "Retiming", and that's what we have as top level menu.

Just to be clear, I think the menu is well done. The issue I wanted to get at is that the feedback on why the keys are greyed out is only availible in this nested menu. The toggle itself is too hidden and is guaranteed to lead to confusion and unnecessary troubleshooting.

Having a prominent toggle on the strip or prominently in the sidebar helps in identifying the state of the strip and presents a button to change it. Especially if the shortcut is pressed by accident (or out of old Refreshing habit) this will help a lot.

> As long as there is a keyboard shortcut, having logical nesting does not seem to be a problem. The context for that command is "Retiming", and that's what we have as top level menu. Just to be clear, I think the menu is well done. The issue I wanted to get at is that the feedback on why the keys are greyed out is **only** availible in this nested menu. The toggle itself is too hidden and is guaranteed to lead to confusion and unnecessary troubleshooting. Having a prominent toggle on the strip or prominently in the sidebar helps in identifying the state of the strip and presents a button to change it. Especially if the shortcut is pressed by accident (or out of old Refreshing habit) this will help a lot.

Julien Kaspar commented 2023-10-02 10:17:08 +02:00

Member

Copy Link

Some more issues I've noticed.

I -> Set Retiming Key is creating a key at the playhead position.
But I -> Set Freeze Frame is created at each selected key.

The naming is not making this clear and there are no Tooltips to explain this behavior.
Perhaps the better solution is even to make both operators create a key at the playhead position. Otherwise you first have to create a retiming key, select it and then set a freeze frame.

Also when using Set Freeze Frame it inserts a new key with a predetermined offset.
But it fails to offset all keys to the right, which results in changing the timing of the segment next to it, and even shrinks the predetermined offset if there isn't enough space for the freeze frame key.
This is too destructive with no easy way to fix the altered timing afterwards.
Setting a Freeze Frame must not alter the timing of any segments to the right of it.

Some more issues I've noticed. `I -> Set Retiming Key` is creating a key at the **playhead position**. But `I -> Set Freeze Frame` is created **at each selected key**. The naming is not making this clear and there are no Tooltips to explain this behavior. Perhaps the better solution is even to make both operators create a key at the playhead position. Otherwise you first have to create a retiming key, select it and then set a freeze frame. Also when using `Set Freeze Frame` it inserts a new key with a predetermined offset. But it fails to offset all keys to the right, which results in changing the timing of the segment next to it, and even shrinks the predetermined offset if there isn't enough space for the freeze frame key. This is too destructive with no easy way to fix the altered timing afterwards. Setting a Freeze Frame must not alter the timing of any segments to the right of it.

Richard Antalik referenced this issue 2023-10-03 16:56:03 +02:00

Fix VSE retiming usability issues #113211

Richard Antalik commented 2023-10-03 16:59:31 +02:00

Member

Copy Link

Retiming Toggle

• Ctrl R is not a good shortcut choice imo. It is a very established and frequently used shortcut for Refreshing. It's fair to say that Blender shouldn't need this shortcut,for now it is still absolutely required. Once it is made obsolete we can think about replacing/removing it.

This should be obsolete already. If there are situation where Ctrl+R is still required, they should be reported and fixed.

I am not sure if I can realistically fix remaining issues. At least not easily or quickly.

Set Speed doesn't do anything to selected keys. Unclear if it only applies to the base speed of the strip???

The set speed operator is operating on whole strip if there are no keys inside of strip. If there are, it should operate on selected keys only. Perhaps this functionality should have been split in 2 different operators. If so, I am not sure how I can implement operator to set strip speed with keys inside. I can propose to delete existing keys and make speed uniform.

Deselect All doesn't have a shortcut shown in the menu even though it's Alt A

Perhaps it would be best to not include selection operators in retiming menu, but not all select operators support selecting retiming data. So I can gray out these in select menu.

Keys that have a speed transition still can't be moved. The speed transition can only be scaled
No way to remove speed transition. Should be in the context menu as well

That is bug - it should work will make fix separate to UI changes

I -> Set Retiming Key is creating a key at the playhead position. But I -> Set Freeze Frame is created at each selected key.

This behavior depends on context - normally freeze frame needs start position, so the idea was, that in retiming editing context if you want to create freeze frame, you would select key and use this operator, but that is probably not great workflow.

I will match behavior to inserting normal key. For transitions, it has to operate on keys though.

Setting a Freeze Frame must not alter the timing of any segments to the right of it.

Seems reasonable, will work on that, but so far the solution seems to be quite complex.

In meanwhile, I have submitted PR #113211 for some issues mentioned here

> > ## Retiming Toggle > > - **`Ctrl R`** is not a good shortcut choice imo. It is a very established and frequently used shortcut for Refreshing. It's fair to say that Blender shouldn't need this shortcut,for now it is still absolutely required. Once it is made obsolete we can think about replacing/removing it. > > This should be obsolete already. If there are situation where Ctrl+R is still required, they should be reported and fixed. I am not sure if I can realistically fix remaining issues. At least not easily or quickly. > Set Speed doesn't do anything to selected keys. Unclear if it only applies to the base speed of the strip??? The set speed operator is operating on whole strip if there are no keys inside of strip. If there are, it should operate on selected keys only. Perhaps this functionality should have been split in 2 different operators. If so, I am not sure how I can implement operator to set strip speed with keys inside. I can propose to delete existing keys and make speed uniform. > Deselect All doesn't have a shortcut shown in the menu even though it's Alt A Perhaps it would be best to not include selection operators in retiming menu, but not all select operators support selecting retiming data. So I can gray out these in select menu. > Keys that have a speed transition still can't be moved. The speed transition can only be scaled > No way to remove speed transition. Should be in the context menu as well That is bug - it should work will make fix separate to UI changes > `I -> Set Retiming Key` is creating a key at the playhead position. `But I -> Set Freeze Frame` is created at each selected key. This behavior depends on context - normally freeze frame needs start position, so the idea was, that in retiming editing context if you want to create freeze frame, you would select key and use this operator, but that is probably not great workflow. I will match behavior to inserting normal key. For transitions, it has to operate on keys though. > Setting a Freeze Frame must not alter the timing of any segments to the right of it. Seems reasonable, will work on that, but so far the solution seems to be quite complex. In meanwhile, I have submitted PR #113211 for some issues mentioned here

Richard Antalik referenced this issue from a commit 2023-10-04 19:27:37 +02:00

Fix VSE retiming usability issues

Julien Kaspar commented 2023-11-08 14:49:43 +01:00

Member

Copy Link

Some more notes from testing:

• The shortcut operator on R doesn't work unless the value field is clicked and accepted. Just pressing enter should lead to the same result but doesn't.
• The I shortcut menu is impossible to find in the UI. The menu should be exposed in the retiming menu of the header so the shortcut is discoverable.

And I'd like to emphasize this:
A solution to select all retiming keys to the right of the selected keys should be the highest priority. Soft Cut or shortened strips can make box selecting keys impossible and very tedious. Large strips are time consuming to retime too. The current workflow of manually selecting all keys to the right is very time consuming and error prone.

I'm not sure what the priorities are atm but imo the current UX for retiming keys must be improved for the next release.

Some more notes from testing: - The shortcut operator on `R` doesn't work unless the value field is clicked and accepted. Just pressing enter should lead to the same result but doesn't. - The `I` shortcut menu is impossible to find in the UI. The menu should be exposed in the retiming menu of the header so the shortcut is discoverable. And I'd like to emphasize this: A solution to select all retiming keys to the right of the selected keys should be the highest priority. Soft Cut or shortened strips can make box selecting keys impossible and very tedious. Large strips are time consuming to retime too. The current workflow of manually selecting all keys to the right is very time consuming and error prone. I'm not sure what the priorities are atm but imo the current UX for retiming keys must be improved for the next release.

tintwotin commented 2023-11-09 12:23:57 +01:00

Copy Link

Looking at the UI
Old:

New:
If the below-mentioned changes in the Retiming menu was implemented, it could look like this:

• Toggle Retiming Keys > Edit Keys: The word toggle is redundant since there is a checkbox, Retime is redundant since the entire submenu is called Retime, and since enabling this operator will allow to edit keys, that is properly a better wording. Tooltip needs to be updated too(as keys are visible all the time, "show" is not a good word). Could also be flipped in functionality, and called "Lock Keys". Move the the top of the menu, as it is super important.

• Add Retiming Key > Insert Key: Retiming is redundant, since the menu is called Retime. Insert is used elsewhere for keys(ex. press I in the 3d view)

• Add Transition > Interpolate Key - which indicates that a key needs to be selected. Benzier could maybe be added?

• Freeze Frame Operator: Unclear that it'll convert selected key to freeze-frame, and when no keys are selected it'll insert a Freeze Frame key at Playhead position. This double behavior can lead to confusion. Freeze Frame can't have transitions? Seems odd?

• Delete Retiming Keys > Delete Keys: Tooltip is wrong.

• Reset Retiming > Reset: Tooltip changed to: Delete all retiming keys.

• Set Speed: Seems to be applied on top of the retiming keys and therefore unrelated to retiming, so maybe it would be better if it is exposed in the Strip Sidebar > Video > Speed. Oh, now it seems it is changing the value of the last key, when no keys are selected, and selecting the first key only, the value mirrors the start value of the last key, but it doesn't update the value on the strip? This function seems very confusing and maybe bugged? If kept: Set Speed in the pop-up header is redundant, as the float widget already is called Speed:
  

(Renaming needs to be applied to the "I" menu too)

Sidebar:
Maybe the properties of the active key should be exposed in the sidebar? So the interpolation type, and the various values can be edited there? (Instead of the very confusing Set Speed operator)

Drawing:

• At some timeline zoom levels the Retime box is drawn 1 px outside the Strip, so there is some rounding issue.
  
• At some zoom levels is the height of the retime box 1 px too low and to not cover the numbers.
  
• The selected key colors need more saturation to be able to see that they're actually selected.
• It is very unclear what the orange bar means. Is it working as intented?

Info:
When trying to insert a key, and no strip is selected or playhead isn't overlapping, there needs to be information about this in the statusbar.

Some code for the above-mentioned changes:

class SEQUENCER_MT_strip_retiming(Menu):
    bl_label = "Retiming"

    def draw(self, context):
        is_retiming = context.scene.sequence_editor.selected_retiming_keys
        strip = context.active_sequence_strip
        layout = self.layout

        layout.operator(
            "sequencer.retiming_show",
            icon='CHECKBOX_HLT' if (strip and strip.show_retiming_keys) else 'CHECKBOX_DEHLT',
            text="Edit Keys",
        )

        layout.separator()

        layout.operator("sequencer.retiming_key_add", text="Insert Key")
        layout.operator("sequencer.retiming_freeze_frame_add", text="Insert Freeze Frame Key")

        layout.separator()

        col = layout.column()
        col.operator("sequencer.retiming_transition_add", text="Interpolate Key (Benzier)")
        col.enabled = is_retiming

        layout.separator()

        layout.operator("sequencer.delete", text="Delete Keys")
        col = layout.column()
        col.operator("sequencer.retiming_reset", text="Reset")
        col.enabled = not is_retiming

        layout.separator()

        layout.operator("sequencer.retiming_segment_speed_set")

Looking at the UI Old:  New: If the below-mentioned changes in the Retiming menu was implemented, it could look like this:  - Toggle Retiming Keys > Edit Keys: The word toggle is redundant since there is a checkbox, Retime is redundant since the entire submenu is called Retime, and since enabling this operator will allow to edit keys, that is properly a better wording. Tooltip needs to be updated too(as keys are visible all the time, "show" is not a good word). Could also be flipped in functionality, and called "Lock Keys". Move the the top of the menu, as it is super important. - Add Retiming Key > Insert Key: Retiming is redundant, since the menu is called Retime. Insert is used elsewhere for keys(ex. press I in the 3d view) - Add Transition > Interpolate Key - which indicates that a key needs to be selected. Benzier could maybe be added? - Freeze Frame Operator: Unclear that it'll convert selected key to freeze-frame, and when no keys are selected it'll insert a Freeze Frame key at Playhead position. This double behavior can lead to confusion. Freeze Frame can't have transitions? Seems odd? - Delete Retiming Keys > Delete Keys: Tooltip is wrong. - Reset Retiming > Reset: Tooltip changed to: Delete all retiming keys. - Set Speed: Seems to be applied on top of the retiming keys and therefore unrelated to retiming, so maybe it would be better if it is exposed in the Strip Sidebar > Video > Speed. Oh, now it seems it is changing the value of the last key, when no keys are selected, and selecting the first key only, the value mirrors the start value of the last key, but it doesn't update the value on the strip? This function seems very confusing and maybe bugged? If kept: Set Speed in the pop-up header is redundant, as the float widget already is called Speed:  (Renaming needs to be applied to the "I" menu too) Sidebar: Maybe the properties of the active key should be exposed in the sidebar? So the interpolation type, and the various values can be edited there? (Instead of the very confusing Set Speed operator)  Drawing: - At some timeline zoom levels the Retime box is drawn 1 px outside the Strip, so there is some rounding issue.  - At some zoom levels is the height of the retime box 1 px too low and to not cover the numbers.  - The selected key colors need more saturation to be able to see that they're actually selected. - It is very unclear what the orange bar means. Is it working as intented? Info: When trying to insert a key, and no strip is selected or playhead isn't overlapping, there needs to be information about this in the statusbar. Some code for the above-mentioned changes: ``` class SEQUENCER_MT_strip_retiming(Menu): bl_label = "Retiming" def draw(self, context): is_retiming = context.scene.sequence_editor.selected_retiming_keys strip = context.active_sequence_strip layout = self.layout layout.operator( "sequencer.retiming_show", icon='CHECKBOX_HLT' if (strip and strip.show_retiming_keys) else 'CHECKBOX_DEHLT', text="Edit Keys", ) layout.separator() layout.operator("sequencer.retiming_key_add", text="Insert Key") layout.operator("sequencer.retiming_freeze_frame_add", text="Insert Freeze Frame Key") layout.separator() col = layout.column() col.operator("sequencer.retiming_transition_add", text="Interpolate Key (Benzier)") col.enabled = is_retiming layout.separator() layout.operator("sequencer.delete", text="Delete Keys") col = layout.column() col.operator("sequencer.retiming_reset", text="Reset") col.enabled = not is_retiming layout.separator() layout.operator("sequencer.retiming_segment_speed_set") ```

image.png

26 KiB

image.png

2.9 KiB

image.png

8.3 KiB

image.png

1.1 KiB

image.png

28 KiB

image.png

8.4 KiB

Julien Kaspar commented 2023-12-04 13:45:31 +01:00

Member

Copy Link

Some more usability issues I noticed:

Last keyframe is setting the speed

This is a big issue when retiming. It's always needed to zoom out, select the keyframe at the end of a retiming segment, and then use R to retime the segment, and then zoom back in again.
A huge problem on any strip that is relatively large.

To avoid unnecessary navigating, the Start Keyframe should be selected to set the speed of the segment.

This of course will end up very confusing because the end keyframe would still be dragged to tweak the retiming speed.

Maybe the best course is to use the planned box visualization of keyframes to show and select and operate on whole retiming segments.

Segment timings are not propagated when using 'Set Speed'

I already mentioned before that preserving the speed of retiming segments that are ahead, when adjusting a single keyframes, is a high priority.
A suggested workaround was to box select or otherwise select all keyframes that are after of the keyframe that is going to be tweaked.

The case where this logic will not work is when using 'Set Speed' on a single keyframe. The changes will not propagate to the keyframe right after that one, resulting in unintentionally changing the speed of the retiming segment after it.

Some more usability issues I noticed: ### Last keyframe is setting the speed  This is a big issue when retiming. It's always needed to zoom out, select the keyframe at the end of a retiming segment, and then use `R` to retime the segment, and then zoom back in again. A huge problem on any strip that is relatively large. To avoid unnecessary navigating, the **Start Keyframe** should be selected to set the speed of the segment. This of course will end up very confusing because the end keyframe would still be dragged to tweak the retiming speed. Maybe the best course is to use the planned [box visualization of keyframes](https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/#reworked-timeline) to show and select and operate on whole retiming segments. ### Segment timings are not propagated when using 'Set Speed'  I already mentioned before that preserving the speed of retiming segments that are ahead, when adjusting a single keyframes, is a high priority. A suggested workaround was to box select or otherwise select all keyframes that are after of the keyframe that is going to be tweaked. The case where this logic will not work is when using 'Set Speed' on a single keyframe. The changes will not propagate to the keyframe right after that one, resulting in unintentionally changing the speed of the retiming segment after it.

image.png

10 KiB

image.png

18 KiB

Julien Kaspar commented 2023-12-04 13:48:53 +01:00

Member

Copy Link

Also a side note: Perhaps it's best to transition the feedback and testing notes to devtalk.
It's better to have a discussion in that space and involve more from the community.

Also a side note: Perhaps it's best to transition the feedback and testing notes to devtalk. It's better to have a discussion in that space and involve more from the community.

👍 1

Richard Antalik referenced this issue from a commit 2023-12-13 20:46:31 +01:00

VSE: implement selection of "linked" retiming keys

Richard Antalik referenced this issue from a commit 2023-12-13 20:46:31 +01:00

VSE: Keep exiting retiming when changing speed

Richard Antalik commented 2023-12-13 21:57:45 +01:00

Member

Copy Link

I have pushed 2 features - Ctrl+click will select all remaining keys and added option for set speed to keep retiming and change strip length instead. Now when I write this, I am thinking, that I could have prevented strip to get longer, but that probably isn't super great idea.

i agree with devtalk thread, will create one, and link it here. There we can discuss retiming preservation when translating keys - it's not hard to implement tecnically, but may need few iterations to get it right.

I have pushed 2 features - Ctrl+click will select all remaining keys and added option for set speed to keep retiming and change strip length instead. Now when I write this, I am thinking, that I could have prevented strip to get longer, but that probably isn't super great idea. i agree with devtalk thread, will create one, and link it here. There we can discuss retiming preservation when translating keys - it's not hard to implement tecnically, but may need few iterations to get it right.

❤️ 1

Julien Kaspar commented 2023-12-14 10:37:09 +01:00

Member

Copy Link

@iss That works yes. Although I didn't get the changes of 5092fe60e6 into an existing right click select keymap. Ctrl RMB does nothing in that case.

@iss That works yes. Although I didn't get the changes of 5092fe60e6 into an existing right click select keymap. `Ctrl RMB` does nothing in that case.

Richard Antalik commented 2023-12-17 21:02:19 +01:00

Member

Copy Link

I have created the topic on devtalk - https://devtalk.blender.org/t/vse-strip-retiming-feedback/32581

I have created the topic on devtalk - https://devtalk.blender.org/t/vse-strip-retiming-feedback/32581

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

brush-assets-project

universal-scene-description

fix-121021

blender-v4.1-release

blender-v3.3-release

blender-v3.6-release

blender-v3.6-temp_wmoss_animrig_public

temp-sculpt-dyntopo

gpencil-next

anim/animation-id-113594

blender-v4.0-release

blender-projects-basics

bridge-curves

sculpt-blender

asset-browser-frontend-split

asset-shelf

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-v2.93-release

realtime-clock

sculpt-dev

bevelv2

xr-dev

v4.1.1

v3.6.11

v3.3.18

v4.1.0

v3.3.17

v3.6.10

v3.6.9

v3.3.16

v3.6.8

v3.6.7

v3.3.14

v4.0.2

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels   

Interest

Alembic

  

Interest

Animation & Rigging

  

Interest

Asset Browser

  

Interest

Asset Browser Project Overview

  

Interest

Audio

  

Interest

Automated Testing

  

Interest

Blender Asset Bundle

  

Interest

BlendFile

  

Interest

Collada

  

Interest

Compatibility

This issue affects/is about backward or forward compatibility

  

Interest

Compositing

  

Interest

Core

  

Interest

Cycles

  

Interest

Dependency Graph

  

Interest

Development Management

  

Interest

EEVEE

  

Interest

EEVEE & Viewport

  

Interest

Freestyle

  

Interest

Geometry Nodes

  

Interest

Grease Pencil

  

Interest

ID Management

  

Interest

Images & Movies

  

Interest

Import Export

  

Interest

Line Art

  

Interest

Masking

  

Interest

Metal

  

Interest

Modeling

  

Interest

Modifiers

  

Interest

Motion Tracking

  

Interest

Nodes & Physics

  

Interest

OpenGL

  

Interest

Overlay

  

Interest

Overrides

  

Interest

Performance

  

Interest

Physics

  

Interest

Pipeline, Assets & IO

  

Interest

Platforms, Builds & Tests

  

Interest

Python API

  

Interest

Render & Cycles

  

Interest

Render Pipeline

  

Interest

Sculpt, Paint & Texture

  

Interest

Text Editor

  

Interest

Translations

  

Interest

Triaging

  

Interest

Undo

  

Interest

USD

  

Interest

User Interface

  

Interest

UV Editing

  

Interest

VFX & Video

  

Interest

Video Sequencer

  

Interest

Virtual Reality

  

Interest

Vulkan

  

Interest

Wayland

Issues relating to Wayland windowing support.

  

Interest

Workbench

  

Interest: X11

Issues relating to Xorg/X11 support.

  

Legacy

Blender 2.8 Project

  

Legacy

Milestone 1: Basic, Local Asset Browser

  

Legacy

OpenGL Error

  

Meta

Good First Issue

  

Meta

Papercut

  

Meta

Retrospective

  

Meta

Security

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  

Module

Animation & Rigging

  

Module

Core

  

Module

Development Management

  

Module

EEVEE & Viewport

  

Module

Grease Pencil

  

Module

Modeling

  

Module

Nodes & Physics

  

Module

Pipeline, Assets & IO

  

Module

Platforms, Builds & Tests

  

Module

Python API

  

Module

Render & Cycles

  

Module

Sculpt, Paint & Texture

  

Module

Triaging

  

Module

User Interface

  

Module

VFX & Video

  

Platform

FreeBSD

  

Platform

Linux

  

Platform

macOS

  

Platform

Windows

  

Priority

High

  

Priority

Low

  

Priority

Normal

  

Priority

Unbreak Now!

  

Status

Archived

  

Status

Confirmed

  

Status

Duplicate

  

Status

Needs Info from Developers

  

Status

Needs Information from User

  

Status

Needs Triage

  

Status

Resolved

  

Type

Bug

  

Type

Design

  

Type

Known Issue

  

Type

Patch

  

Type

Report

  

Type

To Do

No Label

Interest

Alembic

Interest

Animation & Rigging

Interest

Asset Browser

Interest

Asset Browser Project Overview

Interest

Audio

Interest

Automated Testing

Interest

Blender Asset Bundle

Interest

BlendFile

Interest

Collada

Interest

Compatibility

Interest

Compositing

Interest

Core

Interest

Cycles

Interest

Dependency Graph

Interest

Development Management

Interest

EEVEE

Interest

EEVEE & Viewport

Interest

Freestyle

Interest

Geometry Nodes

Interest

Grease Pencil

Interest

ID Management

Interest

Images & Movies

Interest

Import Export

Interest

Line Art

Interest

Masking

Interest

Metal

Interest

Modeling

Interest

Modifiers

Interest

Motion Tracking

Interest

Nodes & Physics

Interest

OpenGL

Interest

Overlay

Interest

Overrides

Interest

Performance

Interest

Physics

Interest

Pipeline, Assets & IO

Interest

Platforms, Builds & Tests

Interest

Python API

Interest

Render & Cycles

Interest

Render Pipeline

Interest

Sculpt, Paint & Texture

Interest

Text Editor

Interest

Translations

Interest

Triaging

Interest

Undo

Interest

USD

Interest

User Interface

Interest

UV Editing

Interest

VFX & Video

Interest

Video Sequencer

Interest

Virtual Reality

Interest

Vulkan

Interest

Wayland

Interest

Workbench

Interest: X11

Legacy

Blender 2.8 Project

Legacy

Milestone 1: Basic, Local Asset Browser

Legacy

OpenGL Error

Meta

Good First Issue

Meta

Papercut

Meta

Retrospective

Meta

Security

Module

Animation & Rigging

Module

Core

Module

Development Management

Module

EEVEE & Viewport

Module

Grease Pencil

Module

Modeling

Module

Nodes & Physics

Module

Pipeline, Assets & IO

Module

Platforms, Builds & Tests

Module

Python API

Module

Render & Cycles

Module

Sculpt, Paint & Texture

Module

Triaging

Module

User Interface

Module

VFX & Video

Platform

FreeBSD

Platform

Linux

Platform

macOS

Platform

Windows

Priority

High

Priority

Low

Priority

Normal

Priority

Unbreak Now!

Status

Archived

Status

Confirmed

Status

Duplicate

Status

Needs Info from Developers

Status

Needs Information from User

Status

Needs Triage

Status

Resolved

Type

Bug

Type

Design

Type

Known Issue

Type

Patch

Type

Report

Type

To Do

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Video Sequencer

Assignees

Clear assignees

No Assignees

5 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#112343

No description provided.