Hi all, I have a builder experiment where the trial loop, which contains several fixed-duration (non-slip) routines, is triggered by a simulated key press from the scanner, as described here.
To clarify, should the 0time of the MRI run timecourse correspond to the start timestamp of the trigger screen (e.g., text_trigger.started) plus the reaction time of that triggered keypress (e.g. triggerkey.rt)?
Although the timing of the routines within the trial loop is pretty good (usually not off by more than 1-2 refreshes), the first routine of the first trial in the trial loop seems to be delayed from the above triggerscreen+trigger.rt by ~90ms and sometimes up to 150ms. I’ve uploaded a short dummy version that shows scene pictures where I’m still getting timing delays up to ~90ms for trial loop, and closer to ~50ms for the first trial in subsequent runs.
The first Fix routine just shows two images that are set to ‘constant’ so I’m trying to figure out what else I might do to improve timing-- I’ve tried preloading with ISI in my main script and this didn’t appear to change things. Perhaps there is something in my system that is slowing things down. Thanks!
Hi, I am running into the same issue with Psychopy 2022.2.5 Standalone on a Mac, where the first routine of the first trial in a loop is delayed. Have you discovered a reason or a solution?
Hi, I haven’t found any solution. Someone suggested to me that putting a gap in that first routine might help address timing issues–e.g., having the image/text be presented after 0.5s in the routine rather than at the beginning of the routine, which is how I usually set things up. I tried this and it seems like it might help the timing delays for the first trial of a run on average but, the very first trial of the first run is still delayed by 80+ms and subsequent delays seem to range from under a refresh to ~50ms.
Hoping someone else can weigh in on this. I’ve noticed that more complicated tasks have longer delays, which makes me thing there could be some way to preload things, but I didn’t notice timing changes when stimuli where set during ISI periods rather than ‘every repeat’. Maybe some timing delays will be unavoidable because the script doesn’t know when the trial loop will begin.
Anyone else having this issue? I have recorded first trial onsets that are delayed up to 190ms. The non-slip timing seems to be shortening some of the subsequent routines, especially the first one that starts late, to account for this delay, which seems relevant for the design of the trial loop if there is no way to fix the timing-- i.e., don’t begin loops with duration-sensitive experiment components.
More importantly, I just want to confirm that the onset of the first event (fix) in the run should be e.g., 190ms, with 0ms corresponding to the onset of the triggerwait screen + the rt (time until scanner pulse received).
Not sure if this will fix your issue, but preloading my image stimuli in a static component during ISI’s, as you mentioned in your first post, has made my timings a lot more accurate.
Interesting, thanks-- so for preloading your images, you have them configured as “set during: routineA.ISI” where that ISI is in a routine earlier within the trial loop? Is that routine with the ISI the first routine within the trial loop?
I just checked again and it doesn’t seem to alter the timing for me whether I use the “set during ISI” method or not, and I think I’ve tried placing the ISI at different points as well. I’ve got 5 images to load per loop, but this seems to happen fine with or without the ISI on all but the first pass.
I have a couple of different versions, where the ISI is either before or after the image display (depending on whether I need to collect responses during image presentation or after).
When the ISI is after, I customized the code so that it preloads the image that is supposed appear on the next trial. I have an additional fixation period before the first trial to preload the first image – this was also done programmatically.
Are you using static components to preload your images? I have this as a different component from my ISI component (which is just a fixation cross), although I’m not sure that it is necessary to separate them. However, I think it is important for the routineA.ISI to be static.
Also, an issue I discovered that may not be relevant to you but might be useful to know, is that keyboard responses don’t seem to register during static periods.
Thanks for the info-- yep my configuration was to use a static component during the fixation routine to prepare images for the upcoming routine. It doesn’t seem to have improved timing, but I haven’t tried loading anything for the first pass before the trial loop. This seems like it might help given that it’s the first trial that is most delayed, although logically I’d think having the static period/ISI come first would make loading outside the loop unnecessary.
Does your code for preloading the first loop image reference a stimulus conditions file? If you wouldn’t mind sharing that code maybe I’ll give it a try and see whether it improves the timing. Thanks.
