VSE: Precision mode doesn't take zoom level into account #91396

New Issue

tintwotin · 2021-09-14T10:16:49+02:00

tintwotin commented

2021-09-14 10:16:49 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 462.59

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: 84da05a8b8
Worked: (newest version of Blender that worked as expected)

Short description of error
Precision and move mode(by shortcut keys) doesn't take zoom level into account

Exact steps for others to reproduce the error

Zoom in close to a strip {key Shift B}
G for grab.
Arrow l/r key for move.
Arrow l/r key for precision move.
When zoomed in shift+arrow is that slow it is useless. And just arrow key is much slower than when zoomed out.

{F10411354,size=full}

Btw. the transform by arrow keys is not exposed anywhere.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 462.59 **Blender Version** Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: `84da05a8b8` Worked: (newest version of Blender that worked as expected) **Short description of error** Precision and move mode(by shortcut keys) doesn't take zoom level into account **Exact steps for others to reproduce the error** - Zoom in close to a strip {key Shift B} - G for grab. - Arrow l/r key for move. - Arrow l/r key for precision move. When zoomed in shift+arrow is that slow it is useless. And just arrow key is much slower than when zoomed out. {[F10411354](https://archive.blender.org/developer/F10411354/precision_mode.gif),size=full} Btw. the transform by arrow keys is not exposed anywhere.

tintwotin commented

2021-09-14 10:16:49 +02:00

Added subscriber: @tintwotin

Pratik Borhade commented

2021-09-14 11:48:22 +02:00

Added subscriber: @PratikPB2123

Richard Antalik commented

2021-09-22 20:10:58 +02:00

Added subscriber: @iss

Richard Antalik commented

2021-09-22 20:10:58 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Richard Antalik closed this issue

2021-09-22 20:10:58 +02:00

Richard Antalik commented

2021-09-22 20:10:58 +02:00

This is correct behavior and unfortunately this is currently implemented in a way that it is not possible to override based on zoom level. Precision mode could respect zoom level, but this is still not a bug.

tintwotin commented

2021-09-22 20:55:19 +02:00

Added subscribers: @Sergey, @fsiddi

tintwotin commented

2021-09-22 20:55:19 +02:00

In similar softwares, it is crucial to be able to do precision transform/trim with keys. It's industry standard. One tap one frame no matter the zoom level. Well, it is also crucial to be able to do this in the blender 3d view...

In the VSE, having to tap 60 times in the default 250 frames long timeline with shift and 6 times without to just move a single frame, is both inconsistent with the 3d view and simply makes this feature unuseable in the VSE.

If a feature is unuseable in the 3d view, it's a bug, but in the VSE, it's design... this doesn't make any sense at all and certainly isn't the way to make the VSE more user-friendly.

@fsiddi @Sergey Do you agree on this decision?

In similar softwares, it is crucial to be able to do precision transform/trim with keys. It's industry standard. One tap one frame no matter the zoom level. Well, it is also crucial to be able to do this in the blender 3d view... In the VSE, having to tap 60 times in the default 250 frames long timeline with shift and 6 times without to just move a single frame, is both inconsistent with the 3d view and simply makes this feature unuseable in the VSE. If a feature is unuseable in the 3d view, it's a bug, but in the VSE, it's design... this doesn't make any sense at all and certainly isn't the way to make the VSE more user-friendly. @fsiddi @Sergey Do you agree on this decision?

Richard Antalik commented

2021-09-22 21:42:27 +02:00

In #91396#1224054, @tintwotin wrote:
If a feature is unuseable in the 3d view, it's a bug, but in the VSE, it's design... this doesn't make any sense at all and certainly isn't the way to make the VSE more user-friendly.

I will remind, that way how we classify issues as bugs is quite well defined. See https://wiki.blender.org/wiki/Reference/Not_a_bug for quick reference. Here arrow keys move mouse cursor by 1 pixel, which clearly works, shift key applies fixed ratio to transform values, this also clearly works. I don't think anybody triaging makes decisions based on which area issue affects.

> In #91396#1224054, @tintwotin wrote: > If a feature is unuseable in the 3d view, it's a bug, but in the VSE, it's design... this doesn't make any sense at all and certainly isn't the way to make the VSE more user-friendly. I will remind, that way how we classify issues as bugs is quite well defined. See https://wiki.blender.org/wiki/Reference/Not_a_bug for quick reference. Here arrow keys move mouse cursor by 1 pixel, which clearly works, shift key applies fixed ratio to transform values, this also clearly works. I don't think anybody triaging makes decisions based on which area issue affects.

tintwotin commented

2021-09-22 22:08:09 +02:00

If this feature is working as indented, do you seriously mean that this is the indented usage?

having to tap 60 times in the default 250 frames long timeline with shift and 6 times without to just move a single frame

If this feature is working as indented, do you seriously mean that this is the indented usage? > having to tap 60 times in the default 250 frames long timeline with shift and 6 times without to just move a single frame

Charlie Jolly commented

2021-09-23 11:54:12 +02:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2021-09-23 11:54:12 +02:00

Can this be marked as a known issue? Seems that even though it is not a bug it is something that can be improved.

JT Nelson commented

2021-09-24 01:14:00 +02:00

Added subscriber: @jta

JT Nelson commented

2021-09-24 01:14:00 +02:00

Um, PF/T2T is absolutely correct. Although I've never done this in blender VSE which I do frequently use, I do use Premiere also and have for years used this workflow he mentions. The ability to be zoomed in close and do precise work is crucial. In general over the years, I've learned a quick hack with blender VSE is to put a base of a black strip as a catch all. It's unacceptable to render to a codec with any type of empty space in a video editor. It is a workaround none the less.

So even though this issue does not fit blender's definition of a syntactical bug it does in fact fit the industry standard definition of a logical bug because it prohibits the user in operating the software at a baseline feature level in parity with expected workflows.

So CJ's recommendation of pushing this at least to a known issue or better yet a todo list is essential.

RA/ISS ... Due to blender's call to be more professional by the orgs that have been funding blender's new found financial windfall, I considerately offer the following professional improvements for your consideration in purview.
"This is correct behavior..." - recommended new default response, "This is correct programmatic behavior..."
Reasoning: this is an outright bug by other projects' standards, but it is according to blender definition programmatically working even though it is in fact incorrect user facing behavior.

"... and unfortunately this is currently implemented in a way that it is not possible to override based on zoom level." - recommended new default response, "Due to implementation constraints, this will be moved to known issue or todo status. Thank you for bringing it to our attention."
Reasoning: "... implemented in a way that it is not possible to override..." pushes away the extended blender community and is such a tired excuse in blender code management when new features are being bike shedded over real issues that it's grown to epic unprofessional proportions. You and others making such a small change in tone could really improve moral. Or it can be continued as always, which is stated in one of my fav manager's office signs, "The beatings will continue until moral improves!"

"Precision mode could respect zoom level, but this is still not a bug." - recommended new default response, see above and, "..., but since it is not a syntactical bug issue it will need to be triaged and processed with other known logical bugs. Thanks again for bringing it to our attention."
Reasoning: Again, pushing away the extended blender community contributes to blender's current image of a lack of professionalism. Engaging with professional behavior as requested by funders can help build blender's credibility over all.

Um, PF/T2T is absolutely correct. Although I've never done this in blender VSE which I do frequently use, I do use Premiere also and have for years used this workflow he mentions. The ability to be zoomed in close and do precise work is crucial. In general over the years, I've learned a quick hack with blender VSE is to put a base of a black strip as a catch all. It's unacceptable to render to a codec with any type of empty space in a video editor. It is a workaround none the less. So even though this issue does not fit blender's definition of a syntactical bug it does in fact fit the industry standard definition of a logical bug because it prohibits the user in operating the software at a baseline feature level in parity with expected workflows. So CJ's recommendation of pushing this at least to a known issue or better yet a todo list is essential. RA/ISS ... Due to blender's call to be more professional by the orgs that have been funding blender's new found financial windfall, I considerately offer the following professional improvements for your consideration in purview. "This is correct behavior..." - recommended new default response, "This is correct programmatic behavior..." Reasoning: this is an outright bug by other projects' standards, but it is according to blender definition programmatically working even though it is in fact incorrect user facing behavior. "... and unfortunately this is currently implemented in a way that it is not possible to override based on zoom level." - recommended new default response, "Due to implementation constraints, this will be moved to known issue or todo status. Thank you for bringing it to our attention." Reasoning: "... implemented in a way that it is not possible to override..." pushes away the extended blender community and is such a tired excuse in blender code management when new features are being bike shedded over real issues that it's grown to epic unprofessional proportions. You and others making such a small change in tone could really improve moral. Or it can be continued as always, which is stated in one of my fav manager's office signs, "The beatings will continue until moral improves!" "Precision mode could respect zoom level, but this is still not a bug." - recommended new default response, see above and, "..., but since it is not a syntactical bug issue it will need to be triaged and processed with other known logical bugs. Thanks again for bringing it to our attention." Reasoning: Again, pushing away the extended blender community contributes to blender's current image of a lack of professionalism. Engaging with professional behavior as requested by funders can help build blender's credibility over all.

Francesco Siddi commented

2021-10-10 17:03:09 +02:00

For editors that support fixed units (frames), transforms should be able to follow those units. Further, for such editors, a "precision" transform mode does not make much sense.
I'll look into making a todo for this.

For editors that support fixed units (frames), transforms should be able to follow those units. Further, for such editors, a "precision" transform mode does not make much sense. I'll look into making a todo for this.

tintwotin commented

2022-02-12 21:33:59 +01:00

@fsiddi Did you get around making a to-do for this?

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VSE: Precision mode doesn't take zoom level into account #91396