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

New Issue

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?

Changed status to: 'Open'

Added subscriber: @JoshuaLeung

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).

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.

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

The frame number indicator also uses +

While the stamp > frames uses a .

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

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.* :)

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)...

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...

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.

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: @mont29

Changed status from 'Open' to: 'Archived'

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.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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

Scrollbar issue

Timecode, Rendertime and user prefs