Sequencer - Display timestamps using standard timecodes instead of a custom method #38242

Closed
opened 2014-01-16 07:05:23 +01:00 by Joshua Leung · 16 comments
Member

Currently the sequencer uses a special format for displaying timestamps (as times instead of frames). This method is inconsistent with of every other animation/time editor in Blender.

Of particular concern is that times above a minute are still displayed in terms of seconds. That is, we get things like 62, 83, 104, etc. instead of the more familiar 01:02, 01:23, 01:44

EDIT: Only closer examination, perhaps the main difference/benefit in favour of the sequencer's current techniques appears to be in how these different techniques handle sub-second accuracy/time stamps. Perhaps all that's needed is a way to merge the sub-second handling in with the superior formatting of > 1 minute values...

Am I missing something here?

Currently the sequencer uses a special format for displaying timestamps (as times instead of frames). This method is inconsistent with of every other animation/time editor in Blender. Of particular concern is that times above a minute are still displayed in terms of seconds. That is, we get things like 62, 83, 104, etc. instead of the more familiar 01:02, 01:23, 01:44 EDIT: Only closer examination, perhaps the main difference/benefit in favour of the sequencer's current techniques appears to be in how these different techniques handle sub-second accuracy/time stamps. Perhaps all that's needed is a way to merge the sub-second handling in with the superior formatting of > 1 minute values... Am I missing something here?
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @JoshuaLeung

Added subscriber: @JoshuaLeung

Added subscriber: @AndrewButtery

Added subscriber: @AndrewButtery

Hi,

You can use Ctrl+T to switch between frames and timecode in any of the editors that have a timeline. The VSE is the only editor that defaults to timecode rather than frames on open.

Agree that it is weird that the VSE timecode scroll bar is different (see attached).

undefined

At the moment when dealing with timecode it uses the format: hh:mm:ss+ff. Wouldn't it also be better to move it to hh:mm:ss:ff so it's in line with SMPTE? http://en.wikipedia.org/wiki/SMPTE_timecode

Also, there are some draw problems when you zoom out to an hour.

undefined

Finally, I seem to recall there is an internal 99,999 frame limit or has this been changed? This could be an issue for Gooseberry if the final edit is in VSE as that is around the one hour and six minute mark...

 - andrew
Hi, You can use Ctrl+T to switch between frames and timecode in any of the editors that have a timeline. The VSE is the only editor that defaults to timecode rather than frames on open. Agree that it is weird that the VSE timecode scroll bar is different (see attached). ![undefined](https://archive.blender.org/developer/F69294/undefined) At the moment when dealing with timecode it uses the format: hh:mm:ss+ff. Wouldn't it also be better to move it to hh:mm:ss:ff so it's in line with SMPTE? http://en.wikipedia.org/wiki/SMPTE_timecode Also, there are some draw problems when you zoom out to an hour. ![undefined](https://archive.blender.org/developer/F69301/undefined) Finally, I seem to recall there is an internal 99,999 frame limit or has this been changed? This could be an issue for Gooseberry if the final edit is in VSE as that is around the one hour and six minute mark... - andrew

Added subscribers: @ideasman42, @schlaile

Added subscribers: @ideasman42, @schlaile

The frame number indicator also uses +

undefined

While the stamp > frames uses a .

undefined

Perhaps the best way is to add options to the Interface user prefs to let the user decide what timecode separators they would like so that users can customise it to their region/country/studio standard?

I found where I remembered the frame restriction - image sequences are restricted to 9999 frames (and a unspecified number of balloons).

http://wiki.blender.org/index.php/Doc:2.6/Manual/Sequencer/Usage

 - andrew
The frame number indicator also uses + ![undefined](https://archive.blender.org/developer/F69465/undefined) While the stamp > frames uses a . ![undefined](https://archive.blender.org/developer/F69469/undefined) Perhaps the best way is to add options to the Interface user prefs to let the user decide what timecode separators they would like so that users can customise it to their region/country/studio standard? I found where I remembered the frame restriction - image sequences are restricted to 9999 frames (and a unspecified number of balloons). http://wiki.blender.org/index.php/Doc:2.6/Manual/Sequencer/Usage - andrew
Author
Member

Maybe I worded this incorrectly. I'm not so much worried that the sequencer displays timing in terms of seconds instead of frames by default. Instead, the problem is how it displays timestamps.

Regarding the timestamp styles - we actually have several in the UserPrefs already which can be used to change how timestamps are displayed in every timeline other than the sequencer (which just keeps on using whatever it does).

Maybe I worded this incorrectly. I'm not so much worried that the sequencer displays timing in terms of seconds instead of frames by default. Instead, the problem is how it displays timestamps. Regarding the timestamp styles - we actually have several in the UserPrefs already which can be used to change how timestamps are displayed in every timeline other than the sequencer (which just keeps on using whatever it does).

Hi aligorith,

Thanks for pointing that out. This is the great thing about Blender - you learn something new every day!

I note that the timecode choice in the user prefs do not affect the timecode stamp that is burnt into the render either...

  • andrew

Blender. It's not a destination, it's a journey.

:)

Hi aligorith, Thanks for pointing that out. This is the great thing about Blender - you learn something new every day! I note that the timecode choice in the user prefs do not affect the timecode stamp that is burnt into the render either... - andrew *Blender. It's not a destination, it's a journey.* :)
Author
Member

It might be a good idea to unify those at some point, but there's also the problem of render timestamps needing to be somewhat consistent between computers.

BTW, where does the zoomout problem occur?

It might be a good idea to unify those at some point, but there's also the problem of render timestamps needing to be somewhat consistent between computers. BTW, where does the zoomout problem occur?

Hi Joshua,

Scrollbar issue

I managed to make the zoom out problem occur in the Timeline though it does seem a bit random. It took me a few minutes of zooming in and out before it happened again... I suspect I could make it happen with any time scroll bar as I think they all use the same function (TBC)...

undefined

It seems to draw just fine hh:mm:ss and if I zoom in just one mouse roll it throws in the +ff even though it is still dealing with hours...

undefined

Timecode, Rendertime and user prefs

Agree, RenderTime should be left alone. But Time is the timecode of the frame which currently just does simple time formatting hh:mm:ss.ff

IMHO this should follow the format that the user has defined in the user prefs...

So to address I think we need to do some minor text changes and incorporate the user prefs by doing the following:

  • RenderTime becomes Render Time in UI and render burn in
  • Time becomes Timecode in UI and render burn in
  • The render timecode burn in will respect the format selected in the user prefs.

I've done most of a diff to fix it - Just need to relocate the timecode formatting code to a new file (was discussed and agreed with Campbell via IRC 17 Jan).

- andrew
Hi Joshua, # Scrollbar issue I managed to make the zoom out problem occur in the Timeline though it does seem a bit random. It took me a few minutes of zooming in and out before it happened again... I suspect I could make it happen with any time scroll bar as I think they all use the same function (TBC)... ![undefined](https://archive.blender.org/developer/F69569/undefined) It seems to draw just fine hh:mm:ss and if I zoom in just one mouse roll it throws in the +ff even though it is still dealing with hours... ![undefined](https://archive.blender.org/developer/F69567/undefined) # Timecode, Rendertime and user prefs Agree, RenderTime should be left alone. But Time is the timecode of the frame which currently just does simple time formatting hh:mm:ss.ff IMHO this should follow the format that the user has defined in the user prefs... So to address I think we need to do some minor text changes and incorporate the user prefs by doing the following: - RenderTime becomes Render Time in UI and render burn in - Time becomes Timecode in UI and render burn in - The render timecode burn in will respect the format selected in the user prefs. I've done most of a diff to fix it - Just need to relocate the timecode formatting code to a new file (was discussed and agreed with Campbell via IRC 17 Jan). - andrew

Hi,

Just added diff D227 which has all the stamp timecode changes in it...

- andrew
Hi, Just added diff [D227](https://archive.blender.org/developer/D227) which has all the stamp timecode changes in it... - andrew

Hi Algorith,

Getting back to the original point you made around the Sequencer having a special timecode - I agree with you in that it does not seem justified. The "special" sequence time is almost identical to the Only seconds timecode style in the user preferences. The only difference in formatting is illustrated below.

undefined

So if the user wants to keep the seconds style format they can select it, but I personally would use timecode every time if I had the option.

It's not very hard to make the change (I've already identified where the code is and played with changing it)... so I'm thinking we make the diff and then hand it off to the UI to approve...

What do you think?

  • andrew
Hi Algorith, Getting back to the original point you made around the Sequencer having a special timecode - I agree with you in that it does not seem justified. The "special" sequence time is almost identical to the Only seconds timecode style in the user preferences. The only difference in formatting is illustrated below. ![undefined](https://archive.blender.org/developer/F72053/undefined) So if the user wants to keep the seconds style format they can select it, but I personally would use timecode every time if I had the option. It's not very hard to make the change (I've already identified where the code is and played with changing it)... so I'm thinking we make the diff and then hand it off to the UI to approve... What do you think? - andrew

Added subscriber: @Januz

Added subscriber: @Januz

Added subscriber: @mont29

Added subscriber: @mont29

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Campbell Barton self-assigned this 2016-03-10 06:36:57 +01:00

No resolution or activity in over 3 months,
archiving, listed in the wiki .
Can re-open when we have time to handle this one.

No resolution or activity in over 3 months, archiving, listed in [the wiki ](http://wiki.blender.org/index.php?title=Dev:Source/Development/Todo/UserInterface#Archived_Design_Tasks). Can re-open when we have time to handle this one.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#38242
No description provided.