17Beta - Can't type in Timecode to Navigate

One can no longer type in timecode into the numerical keypad to navigate the timeline.

Typing in 01:01:00:00 on the Num keypad then - "Enter" should jump to 01:01:00:00 on the Edit Page, Color Page, Fusion (or frames) and Fairlight.

This is how Resolve worked from v7-v16. Including "Davinci".
This is the default for decades in Post production. From linear bays to Avid to Flame, Smoke and Premiere.

Please fix this BUG.

[Shrinivas Ramani]

Brendon

This is a feature. It is intended.
viewtopic.php?f=21&t=125040

Improved timecode entry with ... dedicated action.

How is this an improvement? What dedicated action?

01000000 ENTER; goes to timeline timecode. What possibly needed an improvement on that?

Not one seasoned or professional editor would agree this is an improvement.
In fact, it's a detriment. An interruption in workflow.

This change is infuriating, actually. Especially those coming from Avid or Premiere. Or those that work in both, then using Resolve for Color and more finishing purposes.

Please reconsider the ramifications of this. I find it concerning that BMD thinks this is a good idea.

I have been commenting on this since Resolve 17 b1 and had no idea this was an intentional move on BMD part.

The problem for me was that I was using a custom keyboard mapping in Resolve 16 and continued to use it with Resolve 17 and this is what broke the workflow (or at least made it unlikely that I would continue to work as before) since my (=) key was allocated to some other function on the Color page.

Reading the help (new features guide) shows that the Playback > Go To > Timeline is the menu option we want so with the keyboard set to map this to (=) you just hit the (=) key and then start typing a timecode or you can (additionally) enter a +/- to enter an incremental timecode.

I'm not sure that messing with what amounts to an industry standard is such a good idea, however, I understand the intent.

I just discovered that +/- can also be used on their own (without hitting the (=) key first) but the behavior is finicky - sometimes it doesn't work.

Not one seasoned or professional editor would agree this is an improvement.
In fact, it's a detriment. An interruption in workflow.

He's right, Peter. You guys got this one very wrong.

This is not an improvement. This interrupts the workflow substantially. I type in timecode several hundred times a day. Please give us an option to toggle to industry standard Timecode entry. Hugely disruptive decision.

Beta 6 Dropped and this hasn't been Resolved!

I have not seen any indication from BMD that they intend to change this behavior. Seems like the only difference if you have the keyboard mapping setup is having to hit the (=) key before entering an absolute timecode. Is that true or do the +/- keys not work correctly... I've lost track - I'll have to try it again with the default Resolve keyboard.

+ and - work normally.

Absolute timecode entry is the action that deviates from the expected norm.

Brendon

This is a feature. It is intended.

This is not a feature, it is adding YET ANOTHER unnecessary step to editorial.

Editors type in timecode hundreds of times a day. This "Feature" adds a hundred more keys to find and press.
Your "Feature" adds to potential carpel tunnel.

Brendon

This is a feature. It is intended.
viewtopic.php?f=21&t=125040

Improved timecode entry with ... dedicated action.

It is NOT an improvement. It is a Regression.

The ZERO key is the second largest key on the keyboard for a reason. It's placed at the bottom. Editors don't have to hunt for it. They just hit it, activating the timecode and entering the first digit in ONE PRESS! Now, BMD is breaking this up into two steps and calls it an IMPROVEMENT? A FEATURE?

This "Improvement" not only adds a step, its also the least used key! A key buried and surrounded by other keys! Small, like the others! One can even hit 2+2 then ENTER to get 4 WITHOUT THE = KEY?

Ever work in a dark edit room? Find that buried small key with ease. Yeah, this is NOT AN IMPROVEMENT!

PLEASE REVERT THIS BACK!

@Shrinivas Ramani
I understand that you had good intentions. But seeing how nobody here likes your new feature, could you please undo it?

We really don't like it. I haven't seen a single editor on the forums who reacted positively to this feature.

Indeed, this is a new "feature" that nobody wants. In my experience there are solid reasons why certain key combinations have become standard across various editing software. Making an action MORE difficult is very hard to understand, especially when nobody requested the change.

Dear Resolve team,

Please reconsider this feature or at the very least make this behaviour optional through a user setting.
I trust you guy's have had a good reason for this change since you usually have.

However, this small change has a significant negative impact on my daily work. I too enter TC's hundreds of times a day (it feels kinda nice reading here that I'm not the only one BTW).

One scientific reason this change is a bad idea for people like me is that humans can only remember 5-7 bits of information. (So one TC sequence and a couple of shortcuts will work)
Adding these extra keystroke's makes it very difficult for me to get into the zone. I've noticed that I need to double-check the TC's far more often than in R16. Costing me a lot of time.
Not to mention my hand position that needs to change. I used to be able to use my left hand for the I,O, and F9-F12 keys. Now, I need to punch the TAB key all the way on the other side of my keyboard.

So, Thank you for making this great version of Davinci Resolve. I hope you are open to making it even better.
Have a great 2021!

Any updates on this?

Has it been fixed?

Is a fix in the making?

Not yet back to normal.

I've seen no word other than "we did it on purpose" (which comes with the implied "so get use to it". )

Not yet back to normal.

I've seen no word other than "we did it on purpose" (which comes with the implied "so get use to it". )

That is actually really depressing and demotivating. I thought BMD listens to user feedback?
That's what I've heard others say about them.

Brendon
The ZERO key is the second largest key on the keyboard for a reason.

The reason is …*drum roll*… because it is to be pressed by the little finger of the left [!] hand. The numpad for the right hand has the numbers sorted with the 1 topmost to the left, but the 0 in the middle of the bottom line. Both concerns the layout for right-handed users, more precisely, users writing with their pen in the right hand. In the latter case the right hand becomes free for writing after the number was dialed, while the left hand still has to hold the phone handset. In the former case the right hand holds the pen, while the left hand types into the calculating machine. Why the left-handed layout became the standard computer keyboard layout is out of question here. Ad rem:

Which keyboard? The DaVinci Resolve Editor Keyboard has a [0]- and a [00]-button, that are exactly of the same size — missing is a [=]-key on the numpad, though. I was wondering what the 00-button is good for, since [.] would do the [00]-thing. On the other hand I was wondering why Resolve's standard key mapping not refers to the [=]-key, but to a [Num+=]-key as the hotkey for Playback→Go To→Timecode.

Couldn't that [00]-Button be remapped to the [Num+=]-key? For [000]-buttons on numpads is the idiocracy known, not to deliver an additional scancode, but a stupid [0]-multipress: not effectively faster than three manual presses of 0, while increasing the risk to press the wrong [0]-button in the blind.

As a a heavy vi-user, I'd suggest, you were complaining now if it was the other way round: As a matter of consistent operation you always inputted a leading [=] for the input of a go-to-timecode, you would now, without the waste of the slightest thought, always hit the [=]-key while you are looking for the timecode to be input.

That is actually really depressing

Li'l bit. It's never fun to realize your software frustrations will never get handled.

This is probably the most arrogant, stupid, counter-productive, and workflow-breaking move since the acquirement of DaVinci by BMD. "Yeah, we did it just because we want that and we could. Get used to it or get lost."

Seriously, just stop messing with things which are already working perfectly for more than a decade. You want to make an improvement - find a way to do it without breaking something else.

Has it been addressed?

It not only hasn't been corrected in Beta 8, but things have actually been made worse!

Type in 200.

If you're anywhere past the one minute mark in the timeline, you won't go to the correct location. (The two second mark.)

It not only hasn't been corrected in Beta 8, but things have actually been made worse!

Type in 200.

If you're anywhere past the one minute mark in the timeline, you won't go to the correct location. (The two second mark.)

Ugh... yeah. Timecode usage continues to get worse.

Sorry, but I have to be the dissenting opinion here. I am a seasoned, professional editor, and I welcome the new change. I also consider myself a keyboard-centric editor and computer user in general, and a touch typist. I use a 20+ year old original Apple bluetooth wireless extended keyboard.

If you can't find the equals sign without looking down, that's a you problem.

Before R17, timecode entry sucked up all of the number keys for any sort of functionality other than timecode entry, conflicting with even BMD's own shortcuts. The default mappings for "multicam cut to angle [x]" didn't work unless you re-mapped them to use a modifier key, which meant re-mapping at least 10 bindings for "cut to" and probably another 10 for "switch to," without considering the numeric keypad, depending on how you thought the feature should behave... Which means that anyone who was trying to multicam edit with a keyboard was almost certainly doing it differently than the next guy.

Let me preempt your "but multicam sucks" arguments by saying: I'm not advocating it. I'm advocating the liberation of the ten keys at the top row when your fingers are in typing position, for any purpose that you see fit. Mute/solo audio tracks, enable/disable video tracks, direct track selection, whatever, PLUS ten numeric keypad keys, which can have DIFFERENT functions.

Multicam appears to be BMD's intended use, because that's what the default bindings were in R16, they were just broken because they conflicted with timecode entry. Requiring an extra keypress to enable timecode entry mode fixes the problem, and opens up the possibility of using the keys for any custom purpose, whereas, before, there were twenty keys which only served one: timecode entry... boring.

I understand that some people use timecode entry more often than I do, and people who've invested a lot of muscle memory to that task. So I agree that all of those (assistant) editors should be able to revert to legacy timecode entry mode in their user preferences.

I was under the impression that the + and - keys could be used to navigate relative to current timecode, but right now I still have to enter the = key first in order for the timecode field to become active (on the color page).

Is this the intended behavior? I see conflicting comments.

Test machine is as follows:

Resolve Studio 17.0.b8 (17.0B BUILD 27)

macOS 10.14.6
iMacPro1,1
3 GHz Intel Xeon W 10 core
64GB RAM
Radeon Pro Vega 64 16368 MB

I was under the impression that the + and - keys could be used to navigate relative to current timecode, but right now I still have to enter the = key first in order for the timecode field to become active (on the color page).

Is this the intended behavior? I see conflicting comments.

Test machine is as follows:

Resolve Studio 17.0.b8 (17.0B BUILD 27)

macOS 10.14.6
iMacPro1,1
3 GHz Intel Xeon W 10 core
64GB RAM
Radeon Pro Vega 64 16368 MB

Mark - depends on your keyboard mappings - check them out and restore the default Resolve mappings to see how they redefine + and -. I haven't verified this lately but this is the problem I had when first running into this issue for an earlier beta.

@Steve, thank you for the response.

I am using default mappings, but you prompted me to check the keyboard assignments.

It appears that on the color page, + and - on numpad are preferentially assigned to printer light hotkeys, even when printer lights are not activated. I believe this is a change from earlier versions.

On the edit page, + and - on numpad increment and decrement timecode as expected.

The default mappings for "multicam cut to angle [x]" didn't work...

They did for me in very version of Resolve since 12.5.

@Steve, thank you for the response.

I am using default mappings, but you prompted me to check the keyboard assignments.

It appears that on the color page, + and - on numpad are preferentially assigned to printer light hotkeys, even when printer lights are not activated. I believe this is a change from earlier versions.

On the edit page, + and - on numpad increment and decrement timecode as expected.

On the Color page we now must type = to activate the timecode entry box before using + or - to trim.

I have a feeling this change is due to older versions having the timecode entry "hardwired" which does not allow keyboard mapping for these functions. V17 allows these functions to be mapped.

Whatever advantages there might be, I still think the disadvantage ranks.

Timecode entry via Numpad should not require any clicks or keys to activate, nor leading zeros.

Typing in 200 should just...work, taking the playhead to the two second mark, no mater where it currently is.

I just want to add my voice to the chorus here. This is a terrible new 'feature'. Please, PLEASE change it back!

There was no reason to change such a fundamental, useful concept as typing in timecode. It will almost never be the case that editors need to switch multicam angles more often than they need to jump to a timecode (or jump forwards/backwards by a specific number of frames/seconds/minutes). I would much rather have my multicam shortcuts require a modifier key than my timecode entry.

I would much rather have my multicam shortcuts require a modifier key than my timecode entry.

Agreed. But the irony is, they didn't before and don't still. So the decision here is...still mysterious.

It will almost never be the case that editors need to switch multicam angles more often than they need to jump to a timecode (or jump forwards/backwards by a specific number of frames/seconds/minutes).

I'm honestly shocked that so many people think they need to jump an exact number of frames so often. Is it because I use a trackpad that I don't? Swipe left, swipe right, plus maybe a few taps of either the arrow keys or nudge keys has to be less total actions than guessing a t/c interval, bifurcating, and repeating.

I would much rather have my multicam shortcuts require a modifier key than my timecode entry.

1) It doesn't need to be an either/or proposition. All it takes is one checkbox in the user preferences, and we can all live in peace and harmony.

2) Again, forget multicam. This has nothing to do with multicam. It's about twenty keys serving one function versus twenty keys serving twenty functions.

people think they need to jump an exact number of frames so often.

Relative timecode entry hasn't changed. It's still + or - x to move the playhead x frames.

Absolute timecode entry is broken.

We can't just type 200 on the Numpad to move the playhead to the two second mark. That very simple operation (which has been SOP for NLE's since there were NLE's) now requires additional actions to make things work.

That's what folks are complaining about. Those new, additional actions. It's a small thing, but...still a frustrating and unwelcome change.

people think they need to jump an exact number of frames so often.

Relative timecode entry hasn't changed. It's still + or - x to move the playhead x frames.

Absolute timecode entry is broken.

We can't just type 200 on the Numpad to move the playhead to the two second mark. That very simple operation (which has been SOP for NLE's since there were NLE's) now requires additional actions to make things work.

That's what folks are complaining about. Those new, additional actions. It's a small thing, but...still a frustrating and unwelcome change.

yep. I HATE editing in Resolve, but adapted hoping v17 would get better, the promise of a unified Post solution was the appeal. But this alone is "the straw that broke the camel's back". We are moving our facility back to Avid/Premiere for basic Editorial. (Higher end jobs are still Avid). Color is still Resolve, which I still enjoy using. However, as BMD focus's resources on the freebie market, Baselight is looking more and more like our future.

people think they need to jump an exact number of frames so often.

Relative timecode entry hasn't changed. It's still + or - x to move the playhead x frames.

Absolute timecode entry is broken.

We can't just type 200 on the Numpad to move the playhead to the two second mark. That very simple operation (which has been SOP for NLE's since there were NLE's) now requires additional actions to make things work.

That's what folks are complaining about. Those new, additional actions. It's a small thing, but...still a frustrating and unwelcome change.

yep. I HATE editing in Resolve, but adapted hoping v17 would get better, the promise of a unified Post solution was the appeal. But this alone is "the straw that broke the camel's back". We are moving our facility back to Avid/Premiere for basic Editorial. (Higher end jobs are still Avid). Color is still Resolve, which I still enjoy using. However, as BMD focus's resources on the freebie market, Baselight is looking more and more like our future.

I LOVE editing in Resolve. Please leave me out of it.

I LOVE editing in Resolve. Please leave me out of it.

If you post here, you're in it. However, it was not my intention to include you in this response. My post was certainly not directed towards you. Sorry if you took offense.

We can't just type 200 on the Numpad to move the playhead to the two second mark. That very simple operation (which has been SOP for NLE's since there were NLE's)

No, typing 200 has always gone to the 2 second mark within the current minute, THAT's the industry standard (and it is so because that's the way it SHOULD work), and is how Resolve 16 worked, not sure where you're getting your idea from.

Absolute timecode entry is broken.

We can't just type 200 on the Numpad to move the playhead to the two second mark. That very simple operation (which has been SOP for NLE's since there were NLE's) now requires additional actions to make things work.

That's what folks are complaining about. Those new, additional actions. It's a small thing, but...still a frustrating and unwelcome change.

No, typing 200 has always gone to the 2 second mark within the current minute, THAT's the industry standard (and it is so because that's the way it SHOULD work), and is how Resolve 16 worked, not sure where you're getting your idea from.

I'm pretty sure he means "we no longer can't type 200...." he's been pretty vocal about this ABSURD decision by BMD.

Absolute timecode entry is broken.

We can't just type 200 on the Numpad to move the playhead to the two second mark. That very simple operation (which has been SOP for NLE's since there were NLE's) now requires additional actions to make things work.

That's what folks are complaining about. Those new, additional actions. It's a small thing, but...still a frustrating and unwelcome change.

No, typing 200 has always gone to the 2 second mark within the current minute, THAT's the industry standard (and it is so because that's the way it SHOULD work), and is how Resolve 16 worked, not sure where you're getting your idea from.

I'm pretty sure he means "we no longer can't type 200...." he's been pretty vocal about this ABSURD decision by BMD.

No, that's not what he is saying, he says it more explicitly in another post above:

It not only hasn't been corrected in Beta 8, but things have actually been made worse!

Type in 200.

If you're anywhere past the one minute mark in the timeline, you won't go to the correct location. (The two second mark.)

ah. yes. ok. that would be 01000200 enter. which we can no longer do.

I'm Avid trained... its absolute time for me, or +200 for plus two sec, which thankfully still works.

ah. yes. ok. that would be 01000200 enter. which we can no longer do.

I'm Avid trained... its absolute time for me, or +200 for plus two sec, which thankfully still works.

Are we all on the same page here, yet? I feel like the discussion got derailed a bit.

The only difference between T/C entry in 16 and 17 is that you now have to type a leading equals sign. So typing “enter 01000200 enter” should behave exactly as you’d expect.

If it doesn’t, make sure you’re using the “DaVinci Resolve” default set of keybindings. You can customize further from there, but overwriting the now default “Timecode” assignment on the equals key will “break” timecode entry.

I also feel like people are using the word “broken” too loosely, and it’s hard to tell who’s upset that they have to enter a leading equals sign, and who (mistakenly, but with good reason) thinks timecode entry is fundamentally disabled.

My personal position is that a leading equals sign is a good thing, but an option should exist to disable it for those who disagree. I think it wouldn’t take long to grow accustomed, because it’s a consistent requirement before absolute timecode entry.

In the long run, it’s like BMD handed everybody twenty new keys, to which they didn’t have access before, but of course, people are still going to complain.

Here’s an analogy: on Apple computers, you type command-space to summon spotlight, and then type a search query (I’m sure there’s a Windows equivalent). It’s a consistent behavior across the whole operating system, and it’s very convenient and useful.

But nobody ever complains that they have to hit command-space before entering spotlight search mode. That would be ludicrous. If you didn’t have to hit some key combination to summon the search mode, then you’d always be in the search mode; you would never be able to type anything else.

And yet, THAT is exactly the way people here suggest timecode entry should work, based on the sole argument that it’s the way timecode entry has always worked in Resolve and some other NLEs.

Not a good argument, in my opinion.

P.S.

To those whose complaint that the equals sign is too small/difficult to find in the dark: why not re-map the “Timecode” assignment to any other key you prefer?

Sent from my iPad using Tapatalk

that's the way it SHOULD work)

I disagree.

Humans don't write leading zeros.

You don't write 00200 for two-hundred.

But you do write out 10,200 every time you want to say then-thousand-two-hundred.

So 200 should always go to the two second mark.

If you want to go from 1:10:20:00 to 1:10:30:00, then you either type +1000, or you type 1103000. Every time.

But Jason's right. This is separate from now requiring the = sign to navigate. So I'll beg off on this aspect now.

OMG. Resolve is just not for me anymore. Its becoming clear that Resolve is moving in a different direction.

Editors work in Timecode. If your timecode starts with 00: then you type 00: first. if it starts with 01: you type in 01 first to get to absolute timecode.
If you don't work with Dailies, or clients then maybe one doesn't care. But our clients give us timecode from transcripts and dailies.


Yes. we are upset we now have to enter the = key.

The industry standard for over 20 years is just to start typing on the numeric keypad to enter absolute timecode.
When Avid, Premiere, Flame and other standards do this, and Resolve changed it, it screws up one's workflow. Especially if they bounce between applications in the course of a day.

RESOLVE worked this way since its inception! THEY CHANGED IT FOR THE WORSE!

For those who work on laptops, you may like it. But not for editors on workstations with keyboards.

But yes, BMD PLEASE LET US CHOOSE! Avid Editors don't want an = sign. Neither do Premiere. Actually, neither do seasoned Resolve users.

perhaps BMD is catering to editors that uses laptops without a numeric keyboard. IDK. but why add another key step!!!@!@#!#!@!#@$
NOBODY ASKED FOR THIS CHANGE!!!@#!@!@!@!@

And yet, THAT is exactly the way people here suggest timecode entry should work, based on the sole argument that it’s the way timecode entry has always worked in Resolve and some other NLEs.

Not a good argument, in my opinion.

I'll have to respectfully disagree... Changing the workflow of what is considered an industry standard for years without the ability to choose whether to use new a format or not "is not a feature". If BMD added an option in the preferences to choose, that would be fair.

However, to tell people their complaints based on "that's how it's always been done in the past by Resolve and any other package" is just plain silly IMHO...

Example: If BMD changed the the keybind for Playback from Spacebar to another key without the ability to switch back -- people would have a spasm. If I would post a message saying the complaint is not a valid, I'd be in the wrong.

Silly Example: If a car manufacture changed the steering wheel to turn the vehicle the opposite direction in relation to it's input, then complaints based on "it's always been this way, why did you change it" would be considered valid.

that's the way it SHOULD work)

I disagree.

Humans don't write leading zeros.

You don't write 00200 for two-hundred.

But you do write out 10,200 every time you want to say then-thousand-two-hundred.

So 200 should always go to the two second mark.

That's a poor analogy and bad logic, we're not dealing with numbers straight up, we're dealing with timecode. So, you want 200 to go to 2 seconds do you? *Which* 2 seconds? 01:00:02:00, or 00:00:02:00? Your way doesn't take into account the starting timecode of the timeline. Are you going to say 'the first 2 second mark that occurs in the timeline'? Well what if your start timecode is 09:59:50:00, and you want to go to 10:00:55:00. Intuitively you'd press 5500, because that's where your actual footage is, and yet instead you'd end up at 09:59:55:00. The industry standard way (including how Avid does it) doesn't share this flaw.

But nobody ever complains that they have to hit command-space before entering spotlight search mode. That would be ludicrous. If you didn’t have to hit some key combination to summon the search mode, then you’d always be in the search mode; you would never be able to type anything else.

A poor analogy. There's an entirely separate area of the (full sized) keyboard dedicated to timecode, while the rest of the keyboard can be used for everything else, including a second complete set of numbers. The equivalent in your case would be if we had a separate complete keyboard dedicated to search, and yes that would be ludicrous.

And yet, THAT is exactly the way people here suggest timecode entry should work, based on the sole argument that it’s the way timecode entry has always worked in Resolve and some other NLEs.

Actually it's based on it being the better solution for most use cases, and especially when you have to enter many timecodes in a short space of time. For those who use multicam clips* then the number pad would be good for that purpose, but just like the Printer Lights toggle in the Color page, there could be a toggle that switches the numberpad to other shortcuts, and THEN you hit the numberpad enter key to invoke timecode. Or a user preference, which would be the best solution.

* I certainly feel that BMD have messed with things to accommodate the small minority of editors who actually use multicam, and they really shouldn't. A change like this needs to be an option or else you're just saying 'words' to the majority that I don't care to specify here.

I'll have to respectfully disagree... Changing the workflow of what is considered an industry standard for years without the ability to choose whether to use new a format or not "is not a feature". If BMD added an option in the preferences to choose, that would be fair.

A change like this needs to be an option or else you're just saying 'words' to the majority that I don't care to specify here.

I believe I've said that it should be optional in almost every post I've made in this thread, but certainly in the ones which you've both quoted. You're preaching to the choir.

Let's remember that this is beta software. BMD is very good about listening to user feedback, so let's keep this civil, and I wouldn't be surprised if they made it optional very soon.

OMG. Resolve is just not for me anymore. Its becoming clear that Resolve is moving in a different direction.

You keep saying that you're done with Resolve, but you keep coming back and yelling in all-caps. This is not productive.

And yet, THAT is exactly the way people here suggest timecode entry should work, based on the sole argument that it’s the way timecode entry has always worked in Resolve and some other NLEs.

"And yet, THAT is exactly the way people here suggest.."

I didn't say that. Jason Conrad did.

To be clear, I believe BMD should not have changed the the behavior of their own software. It worked like other NLE's for close to ten years of adhering to industry standards.
See my OP.

It adds a step, and infuriates me when I have to enter = to enter timecode now. It broke my workflow and when I adjust and then go back to Avid or Premiere, it breaks my workflow again.

Seasoned Editors work in Timecode. If BMD changes the way we work, its a problem for many editors.