When the ROI object is created at the start of the experiment, within it there’s a core.Clock object created and stored as (in this case) TL_ROI_trial.clock. When the ROI hasn’t started yet, the value of this clock is continuously reset to 0, otherwise it’s allowed to run. So the times recorded should be relative to the start time of your ROI.
With the very large times, I wonder whether it’s that the ROI is starting immediately with the routine, and starting off looked at, so the clock doesn’t have chance to reset… I’ll run some tests and see if that’s possible! As a quick fix, you could set the start time to be the second frame rather than 0?
The minus numbers I’ve got less of an idea about - as the clock is reset to 0 and counts up from there, negative timestamps shouldn’t be possible.
thanks for reading and thinking about this, i am holding off my eyetracking study and waiting for their 2022 release, maybe this will be fixed in new release
I can’t replicate this bug, but I am using the 2022.1 release - it’s out on GitHub but only the .0, which we’re always cautious about over-hyping because it’s not been tested out in the wild yet! Most of the time it’s best to wait for .1 or .2, but in this case I think it’s worth installing and trying again, it may well be that I can’t replicate because it’s been fixed, we did make a few changes to ROI:
Let me know if you still get this bug in 2022.1.0 What eyetracker are you using by the way? I’m testing it out using MouseGaze as I don’t have any eyetrackers, so it may also be that the bug is specific to one eyetracker.
What eyetracker are you using by the way? I’m testing it out using MouseGaze as I don’t have any eyetrackers, so it may also be that the bug is specific to one eyetracker.