View Single Post
Old 06-03-2016, 03:11 AM   #14
msmucr
Human being with feelings
 
Join Date: Jun 2009
Location: Praha, Czech republic
Posts: 588
Default

Quote:
Originally Posted by airon View Post
Found a possible bug .

At 23.976 fps playback, the display seems to upcount a bit too much further down the timeline. Try in at 20-25 minutes to see the effect, comparing the transport clock to the one onscreen.

We really should ask Justin to give us a few simple functions to read out the current clock in an already formatted string. They had to work quite hard to get the clocks correct in Reaper during the past few years.
Hi,

I'm from PAL/25fps country, so I've tested the script mostly with whole number framerates.
But you're true with your observation.. I've tested it with recent Reaper and there seems to be bug in video processor.
I'm using variable "time" (or "project_time" it doesn't matter as it behaves the same), which should return current item or project time in seconds.. that is input value for my TC calculation.
However when non-integer framerates like 23.976 are used, this variable returns incorrect time. You can see currenttime in seconds, if you uncomment last line with string preparation
// #timecode += sprintf(#, " %.3fs", time);

I'm afraid, it's not possible to fix in the script. I'll try to report that.

And of course, if there will be some another variable with formatted timecode string to avoid manual calculation, it would be fantastic, because it would also allow drop-frame timecodes, which is also currently not possible to do with script.

Michal

EDIT.. my bad, there is also another thing related to rounding.. I'll look at this, hopefully improve it and will post an update.
__________________
FRs: Better FX bypass

Last edited by msmucr; 06-03-2016 at 03:19 AM.
msmucr is offline   Reply With Quote