Accumulated > 4 s drift despite using non-slip timing (presenting videos)

Patrick · May 25, 2022, 3:29pm

My experiment was created using builder and listens for a trigger on the parallel port at the start. Then, the “trials” loop goes through my individual randomisation file specifying the sequence of the experiment.

I have a code component in the trial_selector routine which on every loop sets all loops except the loop for the specified condition to 0 repetitions. For example, if the condition name is filler then n_reps_filler is set to 1 and all other loops are set to 0 repetitions (code is in the “Begin Routine” tab). This way, upon every repeat of the trials loop, only the desired condition is actually presented.

Three of the conditions show video files of < 6.5 s length. Because the “NULL” routine is essentially my ISI and has varying length depending on the trial, I’ve used the trick by @Michael described here to make sure that all my routines are green–i.e. that Builder is using non-slip timing:

Looking at the CSV output I now however see that the paradigm accumulates slightly more than 4 seconds of drift over the exactly 25 minutes that the paradigm is supposed to last. That is, instead of 1500 s the paradigm lasts 1504 s. Checking the log more closely confirms that the drift accumulates slowly over the course of the experiment.

Has anyone encountered a similar issue? In my understanding, using non-slip timing should absolutely prevent a drift of more than 4 seconds?

PS: This is PsychoPy 2021.2.3 on Ubuntu Linux running on quite powerful hardware (so that shouldn’t be the issue).

ivan866 · May 25, 2022, 7:24pm

to begin debugging such issues, first thing you have to do is to get rid of Builder and switch to raw python code
this is just how serious projects work
additionally, how do you measure that the experiment lasts longer than expected? with a physical stopwatch? with an internal .Clock timer in psychopy?
the only thing you can trust - and report - considering you are dealing with video stimulus - is the black-white strobe on your display screen, which ideally should be alternating on every frame so that you can count the actual number of frames presented in each video sequence

Patrick · May 25, 2022, 8:35pm

Thanks for getting back! You’re of course right about super-precise timing. I should clarify that this is fMRI, so what I am looking for is what is described in the link I mentioned: I just need roughly precise timing of the experiment (a few ms of drift don’t matter) which PsychoPy should automatically achieve from the builder when all routines are green.

Reading from the CSV log/data file, however, I find a roughly 4s drift accumulating over the 25 minutes time course of the experiment (as calculated from begin and end times of routines, relative to the time of the initial trigger sent to the parallel port that starts the actual experiment).

Michael · May 26, 2022, 1:11am

That is not the general recommendation of the most experienced PsychoPy developers. Builder scripts generally implement best practice code - there are many more ways for a programmer to go wrong by developing their own scripts from scratch than are likely occur in a Builder script.

Our general recommendation is to use Builder to create the general structure of the experiment, and then just use code components to insert custom tweaks as required.

Of course, careful testing is always required, regardless of how the script is developed. I have recently detected a slight timing error in Builder scripts in the latest releases that affects non-slip routines:

github.com/psychopy/psychopy

Apparent off-by-one (or more) timing error in Builder scripts

opened 08:17AM - 10 May 22 UTC

closed 11:22AM - 16 Jun 22 UTC

m-macaskill

🐞 bug 🐍 Py Builder outputs

Builder components can record their`.started` and `.stopped` attributes in the d…atafile, using an absolute time in seconds. In this minimal example, the first text stimulus `t_0` has a specified onset time of 0 s relative to the start of the trial, with subsequent text stimuli having onsets at 2 and 4 s: <img width="662" alt="Screen Shot 2022-05-10 at 19 42 18" src="https://user-images.githubusercontent.com/931027/167575773-0cff245b-d4fb-4494-a249-ae830ba51da5.png"> Over two separate runs of five trials, subtracting the times of onset between the three stimuli gives the following relative onset times (which should be 2.0, 4.0, and 2.0): trial | t2-t0 | t4-t0 | t4-t2 --|-- | -- | -- 0 | 1.9551 | 3.9537 | 1.9986 1 | 1.9833 | 3.9839 | 2.0006 2 | 1.9831 | 3.9840 | 2.0009 3 | 1.9831 | 3.9834 | 2.0003 4 | 1.9836 | 3.9842 | 2.0006 trial | t2-t0 | t4-t0 | t4-t2 -- | -- | -- | -- 0 | 1.9658 | 3.9659 | 2.0001 1 | 1.9841 | 3.9834 | 1.9993 2 | 1.9655 | 3.9837 | 2.0182 3 | 1.9859 | 3.9836 | 1.9977 4 | 1.9678 | 3.9682 | 2.0004 (1) The intervals between the onset of stimuli `t_4` and `t_2` (the third column) are effectively exactly 2.0 seconds, as intended. (2) The intervals between the onset of `t_0` and the later stimuli are shorter than intended, by 1, 2 or even more frames. (3) When subtracting the time of onset of `t_4` from its time of onset on the previous trial, it was short by approximately 1 frame. i.e. this is an empirical measure of the total routine duration, including transitions between one routine and the next, and should be 5.0 seconds in this case. The shortened duration means the timing error would tend to accumulate over loop iterations. This might particularly affect fMRI tasks, and other studies which require multiple consecutive trials on a fixed schedule. The error in relative onset times seems to apply only with respect to stimuli appearing at t = 0, as the relative times between the later stimuli are correct. This would be consistent with the onset of the first stimulus being delayed (e.g. a dropped frame). But that wouldn't be consistent with the overall duration of the trial being apparently shortened by a frame. Because stimuli (and keyboard components) are appearing at times other than intended relative to the start of the routine, this can lead to systematically incorrect measured reaction times. The issue can be more pronounced in the first iteration of a loop, although given the way Builder stimuli are pre-created before the routine, it isn't obvious why there might be such a start-up cost. This issue does not just apply to visual stimuli but also sound stimuli, and presumably other components. It was first noted in a regular experiment, but is easily reproducible in a minimal .psyexp file like the one attached, which was used to generate the values above. It occurs both in fullscreen and windowed modes. This has been observed when running local Python scripts: I haven't tested it on Pavlovia. Example file below. I just calculated the time intervals manually, by opening the .csv files in a spreadsheet and subtracting columns of `.started` attributes from each other. [timing_issue.psyexp.zip](https://github.com/psychopy/psychopy/files/8659605/timing_issue.psyexp.zip)

@Patrick - the issue I document there appears to go in the opposite direction to what you have encountered. I would encourage you to create a minimal reproducible example and submit it as an issue to the Github repository also.

Note that the trick of forcing Builder to use non-slip timing for routines that do actually have varying durations is a very old one. @jon has subsequently improved the performance of non-slip routine timing (subject to the caveat in the Github issues above), so that may make my ancient work-around no longer necessary. Again, careful testing would be the route here, before adopting tricks that might not be needed anymore.

jon · May 26, 2022, 11:06am

@Patrick I wonder if you could provide a minimal working example of the problem (ie with just enough components, routines and loops to demonstrate it) that I can test on? It’s hard to know from this information where the problem might lie - whether the hack is incorrect or whether there’s an underlying problem

thanks
Jon

Patrick · June 8, 2022, 7:27pm

Dear Jon,
Dear Michael,

Thanks for your responses!

My actual paradigm waits for triggers on the parallel port to start (instead of by pressing space as it is set up now), records responses via the serial port and also send triggers to an eye-tracker. I’ve removed all these additional components to create a minimal working example (MWE) which you can find here in my cloud: https://owncloud.gwdg.de/index.php/s/K6T9FmyKTxvbpUM

The script that I’ve run has the suffix <filename>_non-slip_timing.py and was created using the method for non-slip timing described here. I only include one of my different randomisations here in the folder randomizations/run1/ which is hard-coded in the “trials” loop in the MWE.

The script does nothing else but wait for the user to press space to start, then it presents all trials consecutively as specified in the randomization file. The randomization contains a column called time_s which is the time when a particular trial should ideally start. If I look at the different components and their onset, I can see that they accumulate more and more drift over the duration of the paradigm. The onset of the last fixation cross (fixation_NULL.started) in a trial of type None occurred at 1475.50655293 s but should’ve occurred at around 1471.5 s, thereby accumulating drift of about 4 s. Looking at different onset times in the CSV file I can see that the drift accumulates slowly but steadily.

I’d be very grateful to hear any ideas what is going here, resp. why this is happening?

PS: I’ve had trouble installing the latest version of PschoPy on Ubuntu to see if this might make a difference. I’ll try to get that done and report back in the course of next week.

jon · June 16, 2022, 12:10pm

Hi Patrick, I had a look but there’s still really too much in there for me to work through. There are lots of our code components and they require your serial port (i.e. I’m afraid your Minimal Working Example is neither minimal nor working )

By a MWE we mean literally removing everything that doesn’t isn’t required for the bug to occur. If you remove the End routine, does the problem still occur? Then get rid of the End routine. Does the bug still show when you get rid of the serial port code? Then get rid. etc. You’ll probably have a good idea of most of the things you can get rid of (but I don’t because I’m not sure what’s in all the code comps).

We should end up with 2 or 3 routines, with just a few lines of custom code if needed

Thanks. Sorry, I know this is time consuming to do but it will be less so for you than for me.

For info, I’ve rewritten the non-slip timing method for the upcoming release (2022.2.x) and I’m keen to see if that fixes the issue in your exp.

Topic		Replies	Views
Confusion about how to implement non-slip timing for trials with known end points Coding	14	3306	May 26, 2022
Non-slip timing for variable trial length information from input file Builder	2	1363	September 10, 2017
Non-slip timing - fMRI Coding	3	1520	May 20, 2019
Total run duration differs between computed and measured value Builder timing	6	1078	June 17, 2020
Tracking exact onset/offset time of stimuli Builder	1	1395	June 21, 2019

Accumulated > 4 s drift despite using non-slip timing (presenting videos)

Related Topics