Welcome, Guest
Username: Password: Remember me

TOPIC: Inconsistent frame by frame behavior

Inconsistent frame by frame behavior 21 Mar 2019 14:05 #99375

  • fb_527411383
  • fb_527411383's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 93
  • Thank you received: 7
  • Karma: 2
For a few versions (maybe since 10.4) stepping frame by frame through a project using the left and right arrow keys behaves differently in a project than in a browser clip.
When arrowing in a project, the "Mark" menu item lights up, i.e the arrows are shortcuts for the menu items Mark -> Next/Previous Frame.
When stepping in a browser clip, the Mark menu does not light up, and the frame by frame stepping is smoother. This is most noticeable when using a jog wheel that can produce dozens of steps per second. Jogging through a browser clip is smooth and responsive, but in a project it becomes choppy and laggy.
Does anyone else see this behavior?
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 14:22 #99376

  • Tom Wolsky
  • Tom Wolsky's Avatar
  • OFFLINE
  • Moderator
  • Posts: 4227
  • Thank you received: 677
  • Karma: 109
It looks identical if the project doesn’t need rendering.
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 14:38 #99377

  • fb_527411383
  • fb_527411383's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 93
  • Thank you received: 7
  • Karma: 2
So you're saying that the Mark menu does not light up when stepping through a project, on your machine?
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 14:53 #99378

  • Tom Wolsky
  • Tom Wolsky's Avatar
  • OFFLINE
  • Moderator
  • Posts: 4227
  • Thank you received: 677
  • Karma: 109
The Mark menu is closed in both instances and nothing is highlighted when I open it.
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 14:53 #99379

  • Tom Wolsky
  • Tom Wolsky's Avatar
  • OFFLINE
  • Moderator
  • Posts: 4227
  • Thank you received: 677
  • Karma: 109
The Mark menu is closed in both instances and nothing is highlighted when I open it.
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 14:56 #99380

  • joema
  • joema's Avatar
  • NOW ONLINE
  • Platinum Boarder
  • Posts: 1189
  • Thank you received: 245
  • Karma: 21
On my iMac Pro running 10.4.5, a rendered 4k ProRes timeline is equally smooth using left and right arrow keys vs the same clip in the Event Browser. In the timeline I see the Mark menu blinking with each arrow key press, and it doesn't do this in the Browser. But the responsiveness is the same.

If the timeline is not rendered (ie CTRL+R), contains effects or maybe if it's 4k H264, maybe the timeline would be more laggy than the same clip in the Browser.
Last Edit: 21 Mar 2019 14:56 by joema.
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 15:24 #99381

  • fb_527411383
  • fb_527411383's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 93
  • Thank you received: 7
  • Karma: 2
Okay, that confirms the behavior.
The lagginess has nothing to do with rendering or clip performance; the exact same clip behaves differently in the browser than in a project with no effect or anything that needs to render. The problem seems to be the gui not keeping up with the repeated commands when they are coming in fast (20 per second or more), as with a jog wheel. Jogging through a browser clip is fine, though.
The administrator has disabled public write access.

Inconsistent frame by frame behavior 21 Mar 2019 16:29 #99382

  • joema
  • joema's Avatar
  • NOW ONLINE
  • Platinum Boarder
  • Posts: 1189
  • Thank you received: 245
  • Karma: 21
Further testing shows there is a difference. If I set the Mac keyboard preferences to maximum repeat rate and hold down the right arrow key, the max rate in the timeline is about 21 steps per second. The max rate on that same clip in the Browser is about 32 steps per second.

I've never noticed the difference, probably because the UI is faster than a human could press keys. If a jog wheel is sending repeated arrow keystrokes at a high rate, I see how it might be noticed.

Ideally there should be an efficient programmatic interface for controllers. E.g, when you turn the knob a large distance it doesn't send a bunch of arrow keystrokes but a reposition command or a fast forward command similar to JKL. A fine-grained change could still use arrow keystrokes. I don't remember ever seeing this discussed or requested but it makes sense.

In the meantime using a Magic Mouse or gestures on a Magic Trackpad is very fast and responsive. JKL also very responsive.
Last Edit: 21 Mar 2019 16:31 by joema.
The administrator has disabled public write access.

Inconsistent frame by frame behavior 25 Mar 2019 13:39 #99432

  • fb_527411383
  • fb_527411383's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 93
  • Thank you received: 7
  • Karma: 2
The biggest problem is not necessarily the speed, it is that the keypresses are cached when stepping in a project. That means it will keep stepping for a while after you stop arrowing. A browser clip will stop the moment you stop arrowing (or jogging).
As the desired functionality already is in place for browser clips, there is no need for a specific controller solution, just making project stepping work like browser clip stepping solves everything. As stated, this is in fact how it used to work in previous versions, so I am assuming this behavior is a bug and reporting it to Apple.
The administrator has disabled public write access.