Cycle Select Nearest Edit Point

I use the Select Nearest Edit Point a lot and I would love the ability to quickly cycle through which edit point is targeted when there are multiple clips on different tracks that share the same edit point in the timeline.

Currently, if you have multiple clips on different tracks that share the same edit point in the timeline, Resolve will only select the the edit point of the clip on the lowest track that has its Auto-Track Selector enabled. So in order to select an edit point on a different track, you would have to disable the Auto-Track Selectors of all the tracks you don't want to target, use your hotkey to select the nearest edit point, then re-enable all the Auto-Track Selectors you just disabled. This is a lot of steps and you also have to remember which tracks you just enabled/ disable.

Instead, it would be nice if you could just keep pressing your hotkey for Select Nearest Edit Point and Resolve would cycle through any edit points on any other enabled track for that frame in the timeline. That way, you don't have to keep juggling which tracks have Auto-Track Selection enabled or disabled, you would just keep cycling until the edit point you want is selected. This would only apply if there are shared edit points on different tracks, if there aren't any other edit points at that time then cycling would do nothing.

Also, I imagine this should work the same for Select Nearest Video Edit Point and Select Nearest Audio Edit Point.

Or, perhaps instead of using repeated hotkey presses to cycle, the Select Above / Below functions could work on Edit Point selections as well instead of just clip selections.

Here's a Gif to demonstrate what this idea would look:

Cycle Selection.gif (27.1 KiB) Viewed 3018 times

My preference would be to have normal track selection where you select the track (which would be highlighted) then any edits on that track would be selected. The up and down arrow keys could be used to move up and down tracks to select the edit point you want. If multiple tracks are selected, then nearest edit point would select all of the edit points on those tracks allowing multiple edit points to be tweaked simultaneously.

Resolve is the only editor I've used that doesn't have this and I don't like it at all. The auto track selection is just clunky and slow. Resolve is still severely lacking in basic editing functions and I hope the Edit page will get a much needed overhaul. Fingers crossed for v19.

That's a great idea, Sean. I'd be happy with that approach too.

+1 for ability to select multiple edit points that share the same point in time.

Whatever the method is, it should be something that can override the Auto-Track Selector. Because the Auto-Track Selector affects the operation of so many other tools, it's something you have to constantly juggle off and back on each time you want to select an edit point on a higher track.

Also, the keyboard hotkeys for enabling / disabling the Auto-Track Selector only go up to 8 tracks, so anything beyond that cannot be navigated with the keyboard.

Whatever the method is, it should be something that can override the Auto-Track Selector.

My preference would be to eliminate auto-track selector entirely and just go with normal track selection. I have yet to encounter a single benefit to having this over the normal track selection that I've used in other editors.

If there are scenarios I'm not aware of where it is beneficial, then a "lock track selection" toggle button could be added to the main toolbar and also a keyboard shortcut. This would function exactly the same as you wouldn't be able to accidentally change the selection state of the tracks.

Because the Auto-Track Selector affects the operation of so many other tools, it's something you have to constantly juggle off and back on each time you want to select an edit point on a higher track.

Yes, pasting clips is another function that is very, very annoying with auto-track selection.

My preference would be to eliminate auto-track selector entirely and just go with normal track selection. I have yet to encounter a single benefit to having this over the normal track selection that I've used in other editors.

Interesting! I think I don’t understand what you mean by auto vs normal track selectors.

“Autoselects” came into being in Final Cut in version 4.2 or 4.3 and came from Avid. Premiere also has them. That’s the Big Three. I’m guessing you don’t want to remove them from those platforms so please elaborate.

Thanks!

Interesting! I think I don’t understand what you mean by auto vs normal track selectors.

What I mean by normal track selection is clicking on a track to select it, like in Fairlight. If you click on another track, it is selected and the previous track is deselected. Ctrl or Shift are used to select multiple tracks at the same time.

“Autoselects” came into being in Final Cut in version 4.2 or 4.3 and came from Avid. Premiere also has them. That’s the Big Three. I’m guessing you don’t want to remove them from those platforms so please elaborate.

I've never used any of those and I have no plans on moving to any of them, so I don't have any opinions on what they should do. I'm only concerned about the software I use. I come from Vegas Pro which did track selection by clicking on the track. I'm also primary an audio guy, so most of the editors I've used are DAWs which also do it this way.

Having used both methods, I have found no positives to auto track selection and only negatives. Are there any scenarios where auto selection would be preferred over click select?

I think it’s mostly about being able to deselect tracks whose clips would normally be acted upon by whatever command you were doing. Like if you want to ripple everything but stuff on the music tracks. Or you want to ripple only the dialog tracks.

I would love to read an article about the general rationale for auto-selects as I imagine there are more things to do with it than I’ve imagined. It sure does add complexity - I was horrified when they appeared in FCP4.3!

I think it’s mostly about being able to deselect tracks whose clips would normally be acted upon by whatever command you were doing. Like if you want to ripple everything but stuff on the music tracks. Or you want to ripple only the dialog tracks.

If ripple were to follow track selection, then the tracks could be selected and locked (as I mentioned before) so the track selection doesn't change while editing. Another option, Resolve does already have a track lock feature. You could lock the music track(s) and then ripple would apply to everything else whether the tracks are selected or not.

The rest of my post is more relevant I think.
There's a reason all the major editing platforms have autoselects. I'm not sure of the whole story but this isn't a case where Resolve went off on its own. So I hope it doesn't go off on its own now - but rather figures out what it's doing vis a vis autoselects that's different than the other platforms and makes things harder for editors.

So I hope it doesn't go off on its own now - but rather figures out what it's doing vis a vis autoselects that's different than the other platforms and makes things harder for editors.

I've never used any of the other NLEs with auto track select, but I'm not sure I'd like it any better in any of the other editors. I'd like to hear about the specific tasks that auto track selection is geared towards because I imagine click to select could be tweaked to work for those tasks as well.

My former NLE Vegas Pro started out as a DAW and when it added video it kept the same editing style for video, so it deviated from the conventional NLE style of editing. While Vegas Pro certainly lacks in other areas it is amazing for editing.

I too would like to read about how the autoselects came to be. I tried to google it but without success so far.

I get that you love Vegas and the DAW model of editing video but that’s not the way most users think of video editing. So it’s the same uphill battle that FCPX chose. Which is the opposite of what Resolve Edit was made for. Resolve Edit was made to try and capture the huge body of users who loved FCP7 and were abandoned when Apple killed it.

FCP7 and Premiere can’t from Avid. If one really wants to understand how video/film editing is done in the biggest mission critical market I think Avid is “required reading.” And deviating from their MODEL risks alienating that huge market so is usually a bad decision for a company like BMD who cares about those users.

On the other hand, there’s a whole industry that’s grown up imitating Avid but with an easier, more modern UI. The original FCP and Premiere being the most successful examples.

Resolve Edit was from the start going for this market. I think it’s still their target. But it’s been too quick, IMHO, to innovate just to be different and, like moving the window controls or door locks in a car, made things harder by the innovation.

So I hope they get closer to the model here but I’m not quite sure what about the autoselects is gratuitously different that’s making them harder to use than in FCP7, Premiere, or Avid.

PS Sorry Phillip - looks like we’ve hacked your thread. I think you’ve got a good request there with rotating through the selected edit point. Cheers!

Yeah, all I can find are explanations of how to use it but nothing on how it came to be, why it's still used, or specific pros and cons compared to click to select tracks.

FCPX completely redesigned the timeline in a very bizarre way. I've watched videos on it and if I had been using FCP prior to the magnetic timeline, I would have switched to something else. Track selection is nowhere near as major of a change.

Is it more important to implement features based on their own merits like speed, flexibility, intuitiveness, etc. or because that's just the way legacy applications have always done it? I don't see a reason why there should be such massive differences in how the clips are edited because they contain video information instead of audio information. Vegas Pro showed that a video editor can function like an audio editor and it is amazing. Resolve also has a DAW built in and it would be beneficial to have consistency between the Edit and Fairlight pages.

Finally, I'll say our discussion is still on topic because it's about how best to implement the original feature request. The OP also said they'd be happy with using normal track selection to select edits. This has been a productive discussion weighing the pros and cons of implementing the feature, which is very different from the typical hijacking that happens on this forum where a few individuals just argue against feature requests for no good reason.

I agree with you on all counts. The only place I diverge is that I’m imagining there’s something really good about autoselects of which I’m just not aware. Even though I’ve been editing features for over 20 years I know there’s still plenty I have to learn. That’s why I’d love to find that autoselects discussion that showed how and why they came to be.

The only place I diverge is that I’m imagining there’s something really good about autoselects of which I’m just not aware.

But if we can functionally get to the same place, then that something auto select is really good at could also be done with normal track selection.

The idea behind auto-track select is that all tracks with auto-select enabled are affected and all tracks with auto-select disabled are not. You could accomplish this same thing using simple selection where selected tracks are affected and unselected tracks are not affected. It's the same idea:
Selected track = auto-select ENABLED
Unselected track = auto-select DISABLED

It's just that setting up the selection is more intuitive and faster by clicking on the track(s) you want to select and there are many other benefits to normal track selection too (selecting multiple tracks to temporarily group controls, move multiple tracks at the same time, and more regarding additional feature requests I have but this is certainly going outside the scope of this thread). Then the issue would be if you setup track selection for a certain task (like importing media from the the media pool for example), how best to prevent accidentally changing the selected tracks. One way to accomplish this would be a selection lock so that even clicking inside the timeline would not change your selected tracks. This could be done for the entire project and maybe selection lock buttons on each track as well. This would be very similar to the current auto-track selection, but we wouldn't be forced into using it like we are now.

Worst case scenario where there is no way to implement what auto-select does, then we could have switchable editing modes to change between using click to select tracks and auto-track selection. I'm not sure this is necessary, but even if it was, I'd be fine with this as long as I can change it.

Interesting! To me what you’ve just described is autoselects plus normal track selection - functionally that is. The difference being that normal track selection would be for when you’re wanting to briefly target one or maybe two tracks and autoselects for when you want to target multiple specific tracks for a while.

So I think I now kinda see - if I squint - why they might’ve settled on autoselects and why it’d be a good addition to have normal track selection as well. Basically autoselects are sticky. You’ve GOT to reset them to normal when you’re done. Normal track selection clears to “All tracks are equal” by simply clearing the selection. Just like… normal selection.

If we were starting from scratch I think your scheme of locking the selection is better cause it’s simpler and more visually clear. But given history and leveraging mental models from other editing platforms - plus that the autoselects area is also where the patch panel goes in other NLEs and thus may go if Resolve ever gets it - I think it’s better to just add the layer of normal track selection.

Of course reasonable people may disagree!

To me what you’ve just described is autoselects plus normal track selection - functionally that is. The difference being that normal track selection would be for when you’re wanting to briefly target one or maybe two tracks and autoselects for when you want to target multiple specific tracks for a while.

Yes, you are correct. Having the functionality of both is exactly what I was going for.

If we were starting from scratch I think your scheme of locking the selection is better cause it’s simpler and more visually clear. But given history and leveraging mental models from other editing platforms - plus that the autoselects area is also where the patch panel goes in other NLEs and thus may go if Resolve ever gets it - I think it’s better to just add the layer of normal track selection.

Even if normal track selection was added on top, there would still need to be a selection lock or an override for normal selection. For example, if you setup auto select on certain tracks, what happens if you accidentally click on another track and select it? If you only intended for auto-select tracks to be active, then the accidental normal select would fighting against this.

If starting over is more intuitive and simpler, then it'd be better to do it that way instead of trying to force in legacy features. This frequently causes more problems.

I think normal selection overrides the autoselects and call it done.

I think most people would never need to touch the autoselects at that point.

But if normal select overrides auto select, then you could still have accidental clicks messing up your auto select. This is what the selection lock would prevent, you could set up the track selection for a particular task and then lock it so that the selection won't change. If the auto select was replaced with selection lock, then I agree, there doesn't seem to be any need for auto select.

But if normal select overrides auto select, then you could still have accidental clicks messing up your auto select. This is what the selection lock would prevent…

Diminishing returns.
If you’re using the autoselects and normal track selection exists you’re probably “a pro.” Plus using the autoselects when normal track selection exists would probably be a rare thing.

Isn’t it about as likely one would forget to hit the lock as one would accidentally make a track selection? Certainly an accidental track selection would be a lot more visible.

As a developer myself, I would never assume that a user using a certain function is a "pro". I try to think of every conceivable way the user could potentially screw something up and minimize that as much as possible. If the feature is there, then users will likely try to use it. The goal should be how to best implement it without causing unnecessary confusion or conflicts.

I think adding a selection lock button on each track would be about as close to the auto select as you could get. You could lock a track in a selected or un-selected state and then clicking on that track won't change its selection. On top of this, a global selection lock would allow you to lock all tracks at once. This makes auto select completely unnecessary and it's a lot more intuitive this way.

Oh gee. Let’s not pull rank. I was a dev for 20 years - including lots of usability and UI design.

We see it differently - and that’s OK. To me it’s a big deal to stick with convention unless the unconventional is WAY better. This to leverage user experience.

BMD will do what it will do. I think we’ve both presented good arguments for them should they happen to read them.

I wasn't trying to pull rank, but from a developers' position I don't see how it's a good thing to assume users who use a particular feature would probably be pros. I'd assume the opposite and then try to remove as many potential problems as possible. That's all.

I don't think it has to be WAY better in order to warrant changes. Even small progress is still progress and many small improvements will add up over time. These kinds of discussions are good though to make sure replacing a feature covers all the same needs and nothing falls through the cracks. But there's nothing that can be done to address keeping a feature around just because it's a convention. All I can say is sometimes progress can't happen without changing conventions, but that doesn't mean progress shouldn't happen.

In this case, repurposing the auto select buttons to be selection lock buttons (in addition to adding a global selection lock) is so close to the original that any negatives of having to slightly adjust to this new way are significantly outweighed by the benefits. Every application is going to have its own learning curve anyways, this would be tiny part of that.

An yeah, I can't say I have my hopes up very high for BMD changing this, but it'd be really, really nice if they did.