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.
