free floating time counter

[Craig F]

Set song start position to 01:00:00:00
Never roll Timecode over midnight (00:00:00:00)
Always use a whole number time base, so 24, 25, 30, or 60 FPS. Not 29.97, and for the love of god never use Drop Frame (unless working to a video that requires it)

just some tips for headache reduction

[its2loud]

Actually, 29.97 drop frame time code is the most accurate frame rate to match elapsed time. So if you want it to elapse most like a clock, that's the rate that should be chosen. Also, it doesn't really matter in your session at all if you're only using the time code display to act like a clock.

What is drop frame used for? Telling time. Reading a drop frame timecode tells you exactly where you are in terms of a chronological clock (think of drop-frame timecode as “time elapsed” on your video), but not how many frames have gone by.

[Studio54]

From your song start, click in the left most box of the hours:mins:secs display and type +client ref time, e.g. +1.25.
This moves your cursor to one minute and twenty five seconds from your start - pop a marker in and you know where the client wants a change ..!

I always have a mono audio track in each session that has a shift alt g region that corresponds to the desired bounce length - I highlight this region and then type the above to locate a client’s time reference.

[BScout]

I endorse the floating time ruler.

Being able to adjust "zero" freely (independent of picture timecode or session start time) would be useful. It also makes discussion easier (you don't have to constantly jump from clip start to locate) and allows a continual conversation.

[Rich Breen]

Originally Posted by its2loud

Actually, 29.97 drop frame time code is the most accurate frame rate to match elapsed time....

Only if you're locked to a 29.97 timebase (e.g. blackburst). Drop frame exists to compensate for the slower-than-real-time frame rate of color video. If you're not locked to blackburst/video then 30fps/non-drop is clock-on-the-wall time elapsed, and Craig is correct that it would be the most useful frame rate for this application.

Originally Posted by BScout

I endorse the floating time ruler.

Being able to adjust "zero" freely (independent of picture timecode or session start time) would be useful. It also makes discussion easier (you don't have to constantly jump from clip start to locate) and allows a continual conversation.

Yeah, no kidding! Seems like such a simple thing. The Sheps offset counter works (if a bit fiddly) as long as you're already using/paying for Soundflow (which I am), and I'm glad it exists, but it's too expensive if this is all you need it for. Local Zero please!

[its2loud]

In this use case scenario we are talking about using TC as a timer that most closely represents actual elapsed time. Not the amount of whole frames that will equally fit into a second of time.

The TC window is strictly being used as a clock reference, therefore 29.97DF is going to be the most accurate.

30 frames per second (30fps) does not directly equal elapsed time. While 30fps refers to the frame rate at which video frames are displayed, it does not specify the exact duration of elapsed time.

29.97df (drop frame) timecode is more accurate for representing elapsed time compared to 30fps timecode. The reason for this is that 29.97df timecode accounts for the slight discrepancy between video frame rates and actual time. Due to historical reasons, video formats like NTSC have a frame rate of 29.97 frames per second, which helps align video playback with real-time durations more accurately. The “df” in 29.97df timecode stands for “drop frame,” which adjusts the timecode slightly to compensate for this discrepancy and maintain synchronization with actual time.

In any case, this is beating a dead horse since the use case scenario is probably for about 3-4 min song in which case the discrepancy between 30fps and 29.97df will be minimal.

A few viable workaround have been offered as means to locate time in a song within Pro Tools. The likelihood of an actual timer being added as a feature is most likely release away, if at all.