VSE snapping defaults #89665

New Issue

Richard Antalik · 2021-07-05T18:41:37+02:00

Richard Antalik commented

2021-07-05 18:41:37 +02:00

Snapping status is stored in tool settings, but it is independent of global scene snapping status. Further snapping parameters are stored in SequencerToolSettings, since it is intended to be best suited for VSE workflow.
Current snapping implementation is important also for new transform mode outlined in D11805, which is still not finished tohugh. this is also VSE/NLE specific mode.

Snapping was enabled by default because visually aids in strip positioning, while still allowing usual workflow. I have no strong opinion about default status here.
Scrubbing snapping - D11745 should be subset of VSE snapping settings, and off by default, because it complicates usual workflow in that user can't smoothly scrub through entire timeline.

Snapping status is stored in tool settings, but it is independent of global scene snapping status. Further snapping parameters are stored in `SequencerToolSettings`, since it is intended to be best suited for VSE workflow. Current snapping implementation is important also for new transform mode outlined in [D11805](https://archive.blender.org/developer/D11805), which is still not finished tohugh. this is also VSE/NLE specific mode. Snapping was enabled by default because visually aids in strip positioning, while still allowing usual workflow. I have no strong opinion about default status here. Scrubbing snapping - [D11745](https://archive.blender.org/developer/D11745) should be subset of VSE snapping settings, and off by default, because it complicates usual workflow in that user can't smoothly scrub through entire timeline.

Richard Antalik commented

2021-07-05 18:41:37 +02:00

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

Richard Antalik commented

2021-07-05 18:41:37 +02:00

Added subscribers: @iss, @jon_b, @Clarence-Brown, @Mathias-Zamecki, @RUben, @zegkljan, @AngelNavarro, @Russ1642, @CarstenWartmann, @Pilgrim1987, @brahem_ayad, @Emi_Martinez, @Karthik-1, @yshui, @gkokmdam, @anonym, @mart0, @JosefR, @MikeFutcher, @Gehrig, @ConradDueck, @AndreaMonzini, @KenzieMac130, @forceengine, @alexeygrigoriev, @OnlyLightMatters, @Bearcat, @massmaster, @fodevaux, @erjiang-3, @DavidGascuena, @Giumo, @solarlune, @piledog, @Grady, @garwell, @2046411367, @AnadinX, @intrah, @slumber, @SolidCapo, @HUSCH, @clayhands, @snuq, @cardboard-2, @Bobo_The_Imp, @christian-clavet, @SteffenD, @GabrielMontagne, @pistolario, @FabioRotondo, @Sparazza, @0o00o0oo, @domingo, @Scaredyfish, @NickPolet, @Pipeliner, @AndyCuccaro, @davidmcsween, @xuekepei, @lsscpp, @Stinaus, @Gorro_Rojo, @LucianoMunoz, @jorsh, @tintwotin, @Jaydead, @TheRedWaxPolice, @Jeroen-Bakker, @StephenSwaney, @JacquesLucke, @Fux, @ErickNyanduKabongo, @dfelinto, @fsiddi, @Sergey

Richard Antalik commented

2021-07-05 18:42:50 +02:00

Added subscribers: @JulianEisel, @ideasman42

Campbell Barton commented

2021-07-08 02:22:39 +02:00

There are some down sides to changing the snap default.

In 2.93 you can say:

By default, holding Ctrl snaps in Blender.

With defaulting snap to enabled, the statement

By default, holding Ctrl will toggle the snap setting, which has different defaults depending on the editor type, the sequencer for example enables this setting by default.

Holding Ctrl snaps is very simple to remember, it works everywhere snap is supported (transform, number buttons, resizing areas, resizing brushes etc).
If each actions author chooses set snap default based on what they think the user wants, it means the user then needs to remember which defaults are set for each editor/tool.

While it's always possible to add exceptions, if this is done in a few more places, this will become annoying for users to have to memorize/second-guess.

Blender users tend to keep their one hand on the keyboard (Ctrl is needed to zoom in the 3D view for example). So having to hold a modifier key to enable snap isn't a high barrier.
This is simple to enable for users who prefer it as default.

Enabling snap by default complicates transforming different kinds of data:

Transforming markers currently ignores the snap setting. Arguably it should follow the snap setting, but in that case defaulting to enabled isn't so useful.
Moving the current frame currently is disabled (although it can optionally follow the snap setting).
While "Slip" doesn't support snap at the moment, if it does we might not want this default since this is more likely users will want smooth frame adjustment in this case.

We can always have check-boxes to disable snap for markers, scrubbing (potentially slip) if the outcome of snapping by default isn't useful, but I think this is a hint that the benefit of enabling by default is adding more trouble than it's worth.

There are some down sides to changing the snap default. In 2.93 you can say: > By default, holding Ctrl snaps in Blender. With defaulting snap to enabled, the statement > By default, holding Ctrl will toggle the snap setting, which has different defaults depending on the editor type, the sequencer for example enables this setting by default. ---- - Holding Ctrl snaps is very simple to remember, it works everywhere snap is supported (transform, number buttons, resizing areas, resizing brushes etc). - If each actions author chooses set snap default based on what they think the user wants, it means the user then needs to remember which defaults are set for each editor/tool. ``` While it's always possible to add exceptions, if this is done in a few more places, this will become annoying for users to have to memorize/second-guess. ``` - Blender users tend to keep their one hand on the keyboard (Ctrl is needed to zoom in the 3D view for example). So having to hold a modifier key to enable snap isn't a high barrier. - This is simple to enable for users who prefer it as default. ---- Enabling snap by default complicates transforming different kinds of data: - Transforming markers currently ignores the snap setting. Arguably it should follow the snap setting, but in that case defaulting to enabled isn't so useful. - Moving the current frame currently is disabled (although it can optionally follow the snap setting). - While "Slip" doesn't support snap at the moment, if it does we might not want this default since this is more likely users will want smooth frame adjustment in this case. We can always have check-boxes to disable snap for markers, scrubbing (potentially slip) if the outcome of snapping by default isn't useful, but I think this is a hint that the benefit of enabling by default is adding more trouble than it's worth.

Francesco Siddi commented

2021-07-08 10:21:37 +02:00

I worked with Richard on the specs for VSE snapping and I understand the "consistency" argument. In video editing workflows it not usual to repeatedly turn snapping on and off depending on the task. As long as that is very accessible (a shortcut to toggle snapping on/off, as well as Ctrl) there is no reason to not preserve consistency with other editors.

Mathias Zamęcki commented

2021-07-08 10:58:32 +02:00

Removed subscriber: @Mathias-Zamecki

tintwotin commented

2021-07-08 11:03:56 +02:00

In #89665#1188462, @fsiddi wrote:
there is no reason to not preserve consistency with other editors.

... except the opinion of the users: https://youtu.be/pVMCjLgwN_k?t=1207

> In #89665#1188462, @fsiddi wrote: > there is no reason to not preserve consistency with other editors. ... except the opinion of the users: https://youtu.be/pVMCjLgwN_k?t=1207

Campbell Barton commented

2021-07-09 02:12:46 +02:00

In #89665#1188485, @tintwotin wrote:

In #89665#1188462, @fsiddi wrote:
there is no reason to not preserve consistency with other editors.

... except the opinion of the users: https://youtu.be/pVMCjLgwN_k?t=1207

I believe the way the question was formulated gives a bias, especially since it doesn't mention any of the down-sides.

This is not to discount user input, however users need to be aware of problems an change introduces and be able to give feedback on how these issues might be resolved.

> In #89665#1188485, @tintwotin wrote: >> In #89665#1188462, @fsiddi wrote: >> there is no reason to not preserve consistency with other editors. > > ... except the opinion of the users: https://youtu.be/pVMCjLgwN_k?t=1207 I believe the way the question was formulated gives a bias, especially since it doesn't mention any of the down-sides. This is not to discount user input, however users need to be aware of problems an change introduces and be able to give feedback on how these issues might be resolved.

tintwotin commented

2021-07-09 06:15:28 +02:00

If there are downsides, they're downsides no matter what the default setting might be, and should be solved. But if the only downside is inconsistency and enforcing consistency means going against the expectations and opinions of the users, you'll have to ask yourself, if being rigid about consistency was a good idea in the first place?

I guess the main reason to aim for consistency is to make it easy to work in all editors in Blender, but what is "consistency" worth, if being rigid about it means choking and crippling the UX of every editor outside the 3D View editor?

If there are downsides, they're downsides no matter what the default setting might be, and should be solved. But if the only downside is inconsistency and enforcing consistency means going against the expectations and opinions of the users, you'll have to ask yourself, if being rigid about consistency was a good idea in the first place? I guess the main reason to aim for consistency is to make it easy to work in all editors in Blender, but what is "consistency" worth, if being rigid about it means choking and crippling the UX of every editor outside the 3D View editor?

Campbell Barton commented

2021-07-10 08:23:39 +02:00

In #89665#1188886, @tintwotin wrote:
If there are downsides, they're downsides no matter what the default setting might be, and should be solved.

Not true, see my reply regarding transforming other types where snapping is not a good default.

In #89665#1188886, @tintwotin wrote:
I guess the main reason to aim for consistency is to make it easy to work in all editors in Blender, but what is "consistency" worth, if being rigid about it means choking and crippling the UX of every editor outside the 3D View editor?

I believe terms like "choking" and "crippling" over states any advantage gained by this change.

More generally changing defaults is something that should be discussed in detail before committing: see #37518 (Blender Default Settings: Preferences) & #54943 (Blender 2.8 Defaults).

Raising concerns with changes can result in more well thought through changes which take into account factors that might otherwise be overlooked.

> In #89665#1188886, @tintwotin wrote: > If there are downsides, they're downsides no matter what the default setting might be, and should be solved. Not true, see my reply regarding transforming other types where snapping is not a good default. > In #89665#1188886, @tintwotin wrote: > I guess the main reason to aim for consistency is to make it easy to work in all editors in Blender, but what is "consistency" worth, if being rigid about it means choking and crippling the UX of every editor outside the 3D View editor? I believe terms like *"choking"* and *"crippling"* over states any advantage gained by this change. --- More generally changing defaults is something that should be discussed in detail before committing: see #37518 (Blender Default Settings: Preferences) & #54943 (Blender 2.8 Defaults). Raising concerns with changes can result in more well thought through changes which take into account factors that might otherwise be overlooked.

tintwotin commented

2021-07-13 14:29:46 +02:00

{F10223161,size=full}
48 votes in total.
Link: https://twitter.com/tintwotin/status/1414561356032917510

{[F10223161](https://archive.blender.org/developer/F10223161/image.png),size=full} 48 votes in total. Link: https://twitter.com/tintwotin/status/1414561356032917510

Campbell Barton commented

2021-07-19 01:52:44 +02:00

If you ask users about a perceived improvement without mentioning any down sides you can normally get the answer you're after.

If you ask users what they want to snap will realize that it's limited to certain cases which means snapping everything by default is not a good default.

It may be that there needs to be a different kind of snapping (some kind of limited smart-snapping).

In that case it should be proposed and developed.

If you ask users about a perceived improvement without mentioning any down sides you can normally get the answer you're after. If you ask users what they want to snap will realize that it's limited to certain cases which means snapping everything by default is not a good default. It may be that there needs to be a different kind of snapping (some kind of limited smart-snapping). In that case it should be proposed and developed.

tintwotin commented

2021-07-19 07:11:38 +02:00

How about you do a user poll or check out the industry standards in this field, so you can ensure whatever comes out of it, is fair to the users, who are actually going to use the VSE?

hudson barkley commented

2021-07-19 08:15:48 +02:00

Ok... as a vse user who has been editing with it for over 10 years... I dont know why ANYONE would want the snapping to be on by default? Or for that matter, why would you want it on at all? The only time I ever use snapping is the ctrl shortcut to temporarily turn it on...

Also, a user poll is not overly relevant to this situation, since the defaults are most going to affect new users, not experienced users (any experienced users would know how to set their own defaults and would know what they want). For the defaults, we need to think of what would be the least confusing for a new user who is jumping in.

Ok... as a vse user who has been editing with it for over 10 years... I dont know why ANYONE would want the snapping to be on by default? Or for that matter, why would you want it on at all? The only time I ever use snapping is the ctrl shortcut to temporarily turn it on... Also, a user poll is not overly relevant to this situation, since the defaults are most going to affect new users, not experienced users (any experienced users would know how to set their own defaults and would know what they want). For the defaults, we need to think of what would be the least confusing for a new user who is jumping in.

tintwotin commented

2021-07-19 08:47:57 +02:00

As mentioned did Pablo ask the users on Blender Today, while informing them about the consistency issue, these are the relevant replies in the YT chat:
{F10227795,size=full}
The replies in the YT chat at this point in time: https://youtu.be/pVMCjLgwN_k?t=1296

On Twitter 81.2% out of 48 votes voted for snapping on by default.
{F10223161,size=full}

These are facts. If it is decided that the default snap setting should be off, it is against this wish of these users. That is also a fact.

As mentioned did Pablo ask the users on `Blender Today`, while informing them about the consistency issue, these are the relevant replies in the YT chat: {[F10227795](https://archive.blender.org/developer/F10227795/image.png),size=full} The replies in the YT chat at this point in time: https://youtu.be/pVMCjLgwN_k?t=1296 On Twitter 81.2% out of 48 votes voted for snapping on by default. {[F10223161](https://archive.blender.org/developer/F10223161/image.png),size=full} These are facts. If it is decided that the default snap setting should be off, it is against this wish of these users. That is also a fact.

Campbell Barton commented

2021-07-19 09:11:44 +02:00

@tintwotin the video linked also has a highly up-voted comment stating that this should not change.

Putting too much weight in user voting at all is quite disputable too.

Note that I'm not disputing that it's possible snapping could be improved - the user poll hints at this.
But changing the defaults is a ham-fisted way to handle this in my opinion since it means we have to disable snapping in situations when it would otherwise make sense.

Further, we should have a UI team that aware of users workflow issues and strives to solve them elegantly, not just shrugging our shoulders and giving up because of some user polls, making lazy, short term decisions that don't serve us well in the long run.

@tintwotin the video linked also has a highly up-voted comment stating that this should not change. Putting too much weight in user voting at all is quite disputable too. Note that I'm not disputing that it's possible snapping could be improved - the user poll hints at this. But changing the defaults is a ham-fisted way to handle this in my opinion since it means we have to disable snapping in situations when it would otherwise make sense. Further, we should have a UI team that aware of users workflow issues and strives to solve them elegantly, not just shrugging our shoulders and giving up because of some user polls, making lazy, short term decisions that don't serve us well in the long run.

Domingo Riesco commented

2021-07-19 13:22:14 +02:00

Snapping is essential for fast assembly of material, which is by default what most users do when starting a new project. Even in more advanced stages of a project moving 'clips' from here to there in any video editing software is common and requires snapping, so blocks fall automatically before or after any other. Actually no-snapping mode is mostly useful for details, to work at a frame by frame level. Not surprising then that most users, including myself, prefer snapping to be on by default.

I'd be up to take part on a UI team. I'm experienced in video and sound editing.

Thumbs up!

Snapping is essential for fast assembly of material, which is by default what most users do when starting a new project. Even in more advanced stages of a project moving 'clips' from here to there in any video editing software is common and requires snapping, so blocks fall automatically before or after any other. Actually no-snapping mode is mostly useful for details, to work at a frame by frame level. Not surprising then that most users, including myself, prefer snapping to be on by default. I'd be up to take part on a UI team. I'm experienced in video and sound editing. Thumbs up!

Francesco Siddi commented

2021-07-19 15:10:10 +02:00

@tintwotin your point is clear, thank you for contributing it. Campbell has also responded clearly on your remarks.
The final decision on this will be taken by the module owners or, in case of lack of consensus, by the admins.
As long as enabling snapping with a shortcut is possible (does not look like it works right now) then it's fine to stick to the "snap off by default" and this discussion can be wrapped up.

@tintwotin your point is clear, thank you for contributing it. Campbell has also responded clearly on your remarks. The final decision on this will be taken by the module owners or, in case of lack of consensus, by the admins. As long as enabling snapping with a shortcut is possible (does not look like it works right now) then it's fine to stick to the "snap off by default" and this discussion can be wrapped up.

blender-admin commented

2021-07-29 10:27:54 +02:00

This issue was referenced by 5c9979ff03

This issue was referenced by 5c9979ff0324d9bc26092037899b24ad69f1c34f

Jon commented

2021-07-30 04:25:50 +02:00

Removed subscriber: @jon_b

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VSE snapping defaults #89665