Ripple Edit Tool BROKEN Q/W keys Do Not Trim a Second Time on Still Playhead

[Kyle24825230ppws]

BROKEN IN 2022-2024 DOES NOT WORK ON FIRST FRAME (PRESSING Q TWICE or W TWICE in a row).

This is a bug.

EXHIBIT: The Playhead resting (Q/W already pressed once) at the head or tail of a clip and pressing Q/W a second time does nothing.
OLD DESIRED FEATURE: The Playhead will trim one frame (Q/W) no matter its timeline position, no matter how many times pressed. 
THERE IS NO BACK BY POPULAR DEMAND "desired functionality". You have created a new feature that has not addressed the four previous threads in this community, and 10+ threads in various online forums. 

UNRESOLVED ISSUE: The above response is a two times slower "workaround" by creating a shortcut key. 

FIX: We need one key press (needs to be Q, and W), for one frame removal. As mentioned earlier, your "back by popular demand" fix "desired functionality" isn't a fix, it's a workaround, and nothing is back. Unfortunately this is unacceptable and as a member of the Directors Guild of Canada can not recommend your Premiere Pro 2024 on future shows.

Please acknowledge and fix this bug back to the stated "OLD DESIRED FEATURE", not functionality as stated above. Thank you. DOUBLE TIME WASTED.

Resolve, and Avid are current solutions we are using at the DGC, Directors Guild of Canada. I'm team Adobe. Please help. 

[Ann Bens]

Its not a bug : moved to idea board.

[MyerPj]

What parts are not working? Is it the W? Because the Q seems to work as before, when you switch the "Q" to the new preference as mentioned in the screenshot you posted. 

[Ben Insler]

Happy New Year @Kyle24825230ppws!

OLD DESIRED FEATURE: The Playhead will trim one frame (Q/W) no matter its timeline position, no matter how many times pressed.

Unfortunately I do think the functionality you were seeing was a bug that got fixed and was never intended to be a feature. When you press Ripple Trim Previous Edit to Playhead (Q) or Ripple Trim Next Edit to Playhead (W), the previous or next edit collapse down with the playhead as the trim is performed.  At that moment, the playehad is positioned over the resulting edit point.  Logically, pressing Q or W again would trim out your entire prevous or next clip in your sequence, since this functionality looks to the next and previous edits, and an edit point beneath the playhead cannot be next or previous, so it would not be considered.  It does appear that we have a protection in place to prevent accidental deletion of clips - if your playhead is directly over an edit, Q and W do not perform their Ripple Trim Previous/Next... functions.  This does follow with the same logic above: current is neither next nor previous, so do nothing.  However, the functionality you are describing, "Ripple Trim Previous/Next... unless curently over an edit point, in which case ignore next/previous and instead perform a different action on the current edit point" is a non-logical change in functionality given the name of the function itself.

Believe me, I understand how once you're used to something that's a reliable shortcut, you lean on it.  As much as this may have proved convenient, the functionality is not correct for the feature itself.

All this said, I feel it's worth noting, your desired functionality is ripple trim.  We do have keyboard mappable functions for Select Nearest Edit Point as Ripple In and Select Nearest Edit Point as Ripple Out which, combined with the keyboard mappable Trim Backward and Trim Forward would effectively allow you to select the A or B side of the current edit and trim accordingly, just as you're used to.  No, it's not all wrapped un into one button, but on the flip side you get back some editing functionality you're missing, like adding frames back if you feel you've trimmed too far.

[Ann Bens]

KBSC: Ripple delete head frame.

[R Neil Haugen]

Ben,

Thanks for the detailed post. "We" around here always appreciate getting good solid information from the devs side of things!

That said ... as a user ... being told that yea, you could do this before with a single tap, but now, we fixed it so you need to use 2/3 taps per action ...

Well, do you understand that every flipping time someone does the multiple-tap replacement action, they will be thinking "I used to do this with ONE tap ... " ...?

There's a huge difference at times, between engineer logic, and user experience. What you're suggesting is logical. But with the implication that hey, it's only another couple taps. Oh, right, after you've searched for and found the right keyshorts to use ... oh, and committed those new keyshorts to memory also ...

So the user 1) has to do some work to setup the replacement action you've laid out and 2) then has to multiple tap keystrokes for EVERY frame they want to cut. Every cut, no longer 1 tap, it's what ... 3 per frame cut?

So, for the user, they will grit and grind their teeth,  as they didn't NEED to hunt up, map, and learn several other keyshorts THEN tap away for awhile each cut before.

[jstrawn]

@R Neil Haugen Please believe me when I tell you that Ben has a very solid (understatement) background as a real world user. He's not just giving you a Dev / Experience Designer point of view.

[Bruce Bullis]

> There's a huge difference at times, between engineer logic, and user experience.

Agreed! Ben definitely understands the user experience, and the team is supportive of the guidance he's provided, and the new functionality. 

[R Neil Haugen]

James,

I expect so. And you as much as anyone know in general I'm quite pleased with the dev staff!

However, this kind of discussion has been a common one over the years, between users and devs for hosts of programs.

My points still stand ...

1) yea, the devs have an entirely logical engineering reason for something ... and

2) many users will still gnash their teeth over this change in behavior.

Prior behavior ... users could ripple-delete the front of the clip with one key-tap, not even a combination ... Q. If they wanted to cut one more, tap one key ... Q ... again.

Now ... first, go to the Keyboard Shorts dialog, figure out what they're called and where, SET keystrokes for the new actions, probably a combination. 

Learn to use your new combination.

And every time you try to cut one additional frame, you need to use a different ... probably multiple-key ... short than before.

And ... you know how many keyboard shorts most of us do have mapped, right?

You know how hard it is to find some new simple keyboard shortcut to apply to another item?

So for many editors, this is not a trivial thing. Where in the past, one hand on keyboard, one hand on mouse ... now, you'll probably need to leave the mouse and have both hands on the keyboard just to delete that one extra frame.

Annoying ... certainly. And not nearly as simple as the explanation may sound.

[Ben Insler]

Thanks @R Neil Haugen - the conversation is always insightful!

1) yea, the devs have an entirely logical engineering reason for something

It's little consolation I know, but I assure you that logical engineering reasoning is continuously evaluated alongside user expectation of functionality, and user experience takes the front seat when exploring any design or change.

2) many users will still gnash their teeth over this change in behavior.

We don't ever want to make changes that unleash any lions.  But, if we're being honest, regardless of convenience, this function operating differently when the playhead is in the middle of a clip versus over an edit is entirely counter to expectation.  If anything at all, it should ripple away the entire next/previous clip as I described above to be accurate to its name.

And ... you know how many keyboard shorts most of us do have mapped, right?

Sigh... yep... sure do.

[R Neil Haugen]

Ben, thanks for popping back in! It's so much more enticing with a bit of informative discussion on anything. Very appreciated!

I think this is one of many things I've run into over the years where I can easily see two seemingly opposite points both being valid.

From an engineering logic, your latter paragraph would seem both logical and correct behavior.

And also, that the previous behavior was never intended and was wrong from a design standpoint. Very understandable.

That said, the previous behavior gave the user both the intended top/tail action, but also a very fast way to trim additional frames. Simple, one finger, never needing to move the keyboard or mouse hand. Simply repeat a tap.

The replacement will require reprogramming the keyboard shorts, and learning a new action to muscle memory. One that, for many users, will require two hands to work a paired modifier key or two with an action key.

Yes, it is logical, and in all, fairly 'simple. But nowhere near as simple, fast, and elegant as the previous behavior. And if requiring a two-handed action, this will be definitely slowing and interrupting the flow of the edit process.

That's the flipside, also valid.

Tis a problem, no question.