Millisecond Forums

Hello,

I mentioned this point in a recent post to this forum, but I'm expanding on it slightly here.
We have an event-related fMRI experiment that we're Inquisit for, to present the stimuli to the participants. For our final set of participants, we had Inquisit record an audit/log file to help us be 100% certain about event timing.
This audit file confirms that our event timing occurs exactly as we expected, EXCEPT when participants did not respond.
On trials for which we had specified a short ITI, if participants did not respond, the onset of the subsequent trial was delayed by ~26-27 ms.
Is this a systematic amount of time that Inquisit is adding due to the process of setting up the next trial (which was maybe delayed while it recorded the lack of a response?)? Or is this a quirk of our specific computer/instance of Inquisit (6.5.1)? If it's the latter, of course no one here on the forum would be able to confirm that.

But if there is evidence or reasoning for the 26ms delay caused by non-response trials, that would be helpful! Here is our script and an example of how we code each trial, below. Thank you! - James

<trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>

+x

 

James Rounds - 6/17/2025

Hello,

I mentioned this point in a recent post to this forum, but I'm expanding on it slightly here.
We have an event-related fMRI experiment that we're Inquisit for, to present the stimuli to the participants. For our final set of participants, we had Inquisit record an audit/log file to help us be 100% certain about event timing.
This audit file confirms that our event timing occurs exactly as we expected, EXCEPT when participants did not respond.
On trials for which we had specified a short ITI, if participants did not respond, the onset of the subsequent trial was delayed by ~26-27 ms.
Is this a systematic amount of time that Inquisit is adding due to the process of setting up the next trial (which was maybe delayed while it recorded the lack of a response?)? Or is this a quirk of our specific computer/instance of Inquisit (6.5.1)? If it's the latter, of course no one here on the forum would be able to confirm that.

But if there is evidence or reasoning for the 26ms delay caused by non-response trials, that would be helpful! Here is our script and an example of how we code each trial, below. Thank you! - James

<trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>

Participants literally have untl the last millisecond to respond, so as long as there's no response, the trial keeps the response listener open until the max. trial duration is reached. In the case where a participant does not respond earlier, then, the trial has to do all the stufff it normally would have done if it had received a response (well) before it timed out: Deallocate memory, write data to disk, etc. Disk access in particular is always costly timing-wise, and that is chiefly where the delay comes from.

If you want to minimize such things, you should always work with sufficiently long pre- and posttrialpauses, as the documentation advises.
https://www.millisecond.com/support/docs/v6/html/howto/howtocontroltiming.htm

+x

 

Dave - 6/17/2025

+x

 

James Rounds - 6/17/2025

Hello,

I mentioned this point in a recent post to this forum, but I'm expanding on it slightly here.
We have an event-related fMRI experiment that we're Inquisit for, to present the stimuli to the participants. For our final set of participants, we had Inquisit record an audit/log file to help us be 100% certain about event timing.
This audit file confirms that our event timing occurs exactly as we expected, EXCEPT when participants did not respond.
On trials for which we had specified a short ITI, if participants did not respond, the onset of the subsequent trial was delayed by ~26-27 ms.
Is this a systematic amount of time that Inquisit is adding due to the process of setting up the next trial (which was maybe delayed while it recorded the lack of a response?)? Or is this a quirk of our specific computer/instance of Inquisit (6.5.1)? If it's the latter, of course no one here on the forum would be able to confirm that.

But if there is evidence or reasoning for the 26ms delay caused by non-response trials, that would be helpful! Here is our script and an example of how we code each trial, below. Thank you! - James

<trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>

Participants literally have untl the last millisecond to respond, so as long as there's no response, the trial keeps the response listener open until the max. trial duration is reached. In the case where a participant does not respond earlier, then, the trial has to do all the stufff it normally would have done if it had received a response (well) before it timed out: Deallocate memory, write data to disk, etc. Disk access in particular is always costly timing-wise, and that is chiefly where the delay comes from.

If you want to minimize such things, you should always work with sufficiently long pre- and posttrialpauses, as the documentation advises.
https://www.millisecond.com/support/docs/v6/html/howto/howtocontroltiming.htm

Perfect, thank you so much. That makes sense and I suppose means that we can't expect or guarantee that this normal back-end processing will always take 26 ms. But if background processes on the computer are kept to a minimum, we can assume delays in the next trial's onset after non-response trials will be the result of the same set of behind-the-scenes processes. So far it seems that it usually costs 26-27 ms before the next trial begins.

And great point about the pre- and posttrialpauses. Since this fMRI experiment uses an event-related design, we had to keep trial durations fixed, different across trials, and in a specific order. So I think if we had adjusted our ITIs to account for the pre- and post-trial pauses, we could have incorporated those. Thank you for reminding us of this!