New post
0

Tallying Time / TRT Field Type

Avatar
Pliny (John Eremic)
None
Follow

Where I'd like to end up: a Field Type that allows me to record _and_ tally durations in hours, minutes, seconds (frames optional).


Options:

  • Make the "Timecode" Field Type eligible for sums under Summaries.  However, this would involve a separate feature request: making the timebase user-definable (24, 25, 30fps).
  • Create a new Field Type that records hours, minutes, and seconds (no frames), and make it eligible for sums under Summaries.  This Field Type would not be tied to dates or a specific fps.  This would differ from Duration mainly in scale -- hours, minutes, seconds instead of days, hours.  I would call this Field Type TRT (Total Running Time).

In either case, I would not want the hours not to be tied to an arbirary 24-hour limit or rollover.  In other words, 168 hours, 5 minutes, and 11 seconds would be represented as 168:05:11[:00].

Thoughts?

Date Votes

5 comments

  • 0
    Avatar
    Isaac Reuben

    Hey John,

    I think we should definitely be able to add a Sum option for Timecode fields.  I just created a ticket for that. 

    We will eventually be adding timebase options for that field, because it's tricky to fogure out the level to put them at (per field in the field config, per project, per *entry*, so diff entries can have different timebases).  You have any suggestions there? 

    With the addition of the Sum option mentioned above, maybe you could leave the timecode fields at :00 for the frames, and then you could track time down to the second resolution as you were saying, even if the timebases are different.  The timecode field is stored as *time* (not frames) under the hood, to allow for merging together different timebases or displaying different timebase for the same raw value.

    Is that helpful?

  • 0
    Avatar
    Pliny (John Eremic)

    To answer your question first: per entry.  Not sure how that would look, UI-wise.  Tricky.  Perhaps a separate field in the same table/entity denoting the timebase for that clip?

    The :00-frames kludge works in some cases, but in other cases I will be dumping large tables generated directly from media metadata.  So I'll be starting with frame-accurate data.

    If TC is stored as "Time" under the hood, how will it behave/display when a sum exceeds 24 hours?

  • 0
    Avatar
    Pliny (John Eremic)

    A corollary to this: simplify manual input in a TC Field.  Right now the cell "breaks" (turns red) if I type something like 1:19.  To me, the UI should interpret this as 00:00:01:19.  I can't even type 1:00:00:00 -- it has to be 01:00:00:00.  My vote: interpret short entries little-endian, and don't force a leading zero.

  • 0
    Avatar
    Isaac Reuben

    I've also created a ticket about relaxing the validation.

    the field values are stored natively in 1000ths of second, so they add up well,can convert between timebases, and don't wrap over at 24 hours.  Your example value of 168:05:11:00 doesn't work currently because as you mention the validation is too strict and it's limiting the hours part to 2 digits, but 99:05:11:00 works right now.

  • 0
    Avatar
    Pliny (John Eremic)

    Many thanks for your responses here. I'm mostly posting nitpicky stuff right now because (a) the big things already work; (b) the small stuff matters; and (c) I'll hold off big-picture feature requests until I've spent more time with "Shotty".


    Very excited with what I've seen so far.

Please sign in to leave a comment.