+xHi,
I have a question about my inquisit code.
I set a trial to be something like below.
<trial POSO_posBG_shrt_ITI_1pt6>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ timeout = 3200
/ responseinterrupt=frames
/ posttrialpause = 1600+(500-trial.POSO_posBG_shrt_ITI_1pt6.latency)
</trial>
I wrote the trial in this way with the following goals in mind:
(1) Participants can make a response between the time window of 1100 to 3200ms from a trial onset. Their response latency in the trial could range between 0 to 2100ms.
(2) Once they make a response within this window, the poso_goodtarget word will disappear (blank screen starts).
(3) No matter how fast participants make a response or whether they make a response or not, the overall duration of a trial plus the immediately following posttrial pause will always be a set value of 3200 + 1600 = 4800.
- If the participant make a response within 500ms (1600ms post trial onset), they will see the blank screen for a longer time (1600 + 500 - latency).
- If the participant make a response between 500 to 2100ms, they will see the blank screen for a longer time.
However, when looking at the saved data file, it doesn't seem like the post-trial pause duration is taking the trial response latency into account.
I attached a simplified version of the experiment and the saved monkey data file. Could you help me understand why the script is not working in the way I intend it to be? Thank you!
> However, when looking at the saved data file, it doesn't seem like the post-trial pause duration is taking the trial response latency into account.
At the time the posttrialpause is determined for the 1st instance of the given trial, there is no latency. Meaning this
/ posttrialpause = 1600+(500-trial.POSO_posBG_shrt_ITI_1pt6.latency)
works out to
/ posttrialpause = 1600+(500-nothing)
i.e. 2100.
Suppose, then, you don't respond in this instance of the trial, i.e. produce a latency of 2100. Then, when the posttrialpause for the next instance of that same trial is calculated, there is a latency, and its value is 2100, meaning
/ posttrialpause = 1600+(500-trial.POSO_posBG_shrt_ITI_1pt6.latency)
works out to
/ posttrialpause = 1600+(500-2100)
i.e. 0.
See in the above how the posttrialpause adjustment is always trailing, i.e. contingent on the latency of the previous instance of the trial.
Your description here
"(3) No matter how fast participants make a response or whether they make a response or not, the overall duration of a trial plus the immediately following posttrial pause will always be a set value of 3200 + 1600 = 4800.
- If the participant make a response within 500ms (1600ms post trial onset), they will see the blank screen for a longer time (1600 + 500 - latency).
- If the participant make a response between 500 to 2100ms, they will see the blank screen for a longer time."
doesn't really make sense to me. If you want the trial to have a fixed duration of 4800, you should use /trialduration (not /timeout) and set it to 4800, with /posttrialpause set to 1600.
https://www.millisecond.com/support/docs/current/html/howto/howtocontroltiming.htmWith respect to
"- If the participant make a response within 500ms (1600ms post trial onset), they will see the blank screen for a longer time (1600 + 500 - latency).
- If the participant make a response between 500 to 2100ms, they will see the blank screen for a longer time."
the blank period in your trial begins as soon as there is a response (i..e. a key press between 1100 and 3200 ms measured from the start of the trial's stimulus presentation sequence). The earlier the response, the longer the blank period. The later the response, the shorter the blank period.
If your approach worked (which it doesn't), then not responding (latency = 2100) in a given trial would result in a posttrialpause of 1600 + (500 - 2100) = 0, virtually no blank period and a trial duration of a mere ~3200 ms, not 4800.