Millisecond Forums » Millisecond Forums » Inquisit 6 » Posttrialpause setup

RE: Posttrialpause setup

Dave — Thu, 13 Apr 2023 01:21:22 GMT

+x[quote]

[b]Libra - 4/13/2023[/b]
Hi Dave,
Thank you so much! this makes a lot of sense. It seems that /trialduration is exactly what I would want.
"/trialduration Specifies the absolute duration of a trial, from beginning to end, including the posttrialpause. If the subject responds quickly, the posttrialpause interval is lengthened to fill out the remaining time in the duration. If the subject does not respond before the duration, the trial is terminated and the next trial begins."

I updated my trial to be like this.

<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
/ trialduration = 4800
/ responseinterrupt=frames
/ posttrialpause = 1600
</trial>

Could I check my understanding with you? Please bear with me, just want to make sure!
In this trial, the maximum span for poso_goodtarget to be presented on the screen is from 1100 to 3200 (4800-1600) from trial onset (and this happens if participants do not make a response). If participants respond, say at 1200ms from trial onset, the latency of this trial will be 100ms. A blank screen immediately starts when participants make the response at 1200ms. So from 1200 to 4800 of this trial, participants will continue to see the blank screen. Then, the next trial begins.

Ideally, I would want to verify this with saved data. Right now a single trial's data tells me the latency, each stimulus onset, and the fixed posttrialpause (for this trial, always 1600ms). So I can't make sure that the entire trial is absolutely 4800ms, no matter how fast participants make a response and whether they make a response or not. Is there a way to save the total block time in the data file? Essentially, if a block only contains trials like these, then the total block duration should be the same for each monkey run. [I tried block.name.timestamp] but it only seems to record the block starting time, right?

Thank you again!
[/quote]

> In this trial, the maximum span for poso_goodtarget to be presented on the screen is from 1100 to 3200 (4800-1600) from trial onset (and this happens if participants do not make a response).

Correct.

> If participants respond, say at 1200ms from trial onset, the latency of this trial will be 100ms.

Correct.

> A blank screen immediately starts when participants make the response at 1200ms.
> So from 1200 to 4800 of this trial, participants will continue to see the blank screen. Then, the next trial begins.

Also correct.

To verify a trial's duration:
- Take the trial's timestamp property in trial N.
- Take the trial's timestamp property in trial N + 1.
- Calculate the absolute difference to verify the duration of trial N.

Example below:

[code]

<data>
/ columns = [date time build subject blocknum blockcode trialnum trialcode response correct latency stimulusitem stimulusitem stimulusitem stimulusitem stimulusonset stimulusonset stimulusonset stimulusonset posttrialpause
values.effectiveBlankPeriod, values.timestampPrevioustrial, values.timestampCurrenttrial, values.previousTrialDuration]
/ labels = true
/ separatefiles = true
</data>

<expt 1>
/ blocks = [1=data_BG1]
</expt>

------------------------------------------------------------------------------------
*** SIGNIFICANT POSITIVE PERSON'S NAME SURVEY ******
------------------------------------------------------------------------------------
<block get_ready_BG>
/ trials = [1=get_ready]
</block>

<block get_ready>
/ trials = [1=get_ready]
</block>

<trial get_ready>
/ stimulusframes = [1 = getready]
/ validresponse = ("5")
</trial>

<text getready>
/items=("Get ready!")
/ position = (50%, 50%)
</text>

<trial block_end>
/ stimulustimes = []
/ responsemode = noresponse
</trial>

<text goodreminder_rightBG>
/ numitems = 1
/ items = ("GOOD")
/ position = (75, 25)
</text>

<text badreminder_leftBG>
/ numitems = 1
/ items = ("BAD")
/ position = (25, 25)
</text>

------------------------------------------------------------------------------------
*** TEXT PRIMES AND TARGETS *****
------------------------------------------------------------------------------------

********** NEW PRIMES ****************

<text responses>
/ txcolor = (0, 0, 0)
/ position = (50,25)
/ fontstyle = ("Verdana", -20, true, true, false, false, 5, 0)
/ items = responseitems
</text>

<item responseitems>
</item>

<text POSO>
/ numitems = 1
/ items = ("POSO")
/ select = noreplace
</text>

<text poso_goodtarget>
/ items=good
/ select = list.poso_goodtargetnumbers.nextvalue
</text>

<item good>
/ 1 = "honor"
/ 2 = "lucky"
/ 3 = "diamond"
/ 4 = "loyal"
/ 5 = "freedom"
/ 6 = "rainbow"
/ 7 = "love"
/ 8 = "honest"
</item>

<list poso_goodtargetnumbers>
/ items = (1,2,3,4,5,6,7,8)
/ poolsize=48
/ selectionmode = random
/ replace = false
</list>

<text blanks>
/ numitems = 3
/ items = (" ", " ", " ")
/ select = noreplace
</text>

----------------------------
<block data_BG1>
/ bgstim = (badreminder_leftBG, goodreminder_rightBG)
/ trials = [1-10 = POSO_posBG_shrt_ITI_1pt6]
</block>

*****
<text fixation>
/ items = ("+")
/ position = (50%, 50%)
</text>
******

**** Positive Object prime *** positive target and negative target *** BG *** short SOA

<values>
/ effectiveBlankPeriod = -1 // calculates effective duration of the blank period
/ timestampCurrenttrial = -1
/ timestampPrevioustrial = -1
/ previousTrialDuration = -1 // calculates the previous trial's duration
</values>

<trial POSO_posBG_shrt_ITI_1pt6>
/ ontrialbegin = [
    values.timestampPrevioustrial = values.timestampCurrenttrial;
    values.timestampCurrenttrial = trial.POSO_posBG_shrt_ITI_1pt6.timestamp;
    values.previousTrialDuration = values.timestampCurrenttrial - values.timestampPrevioustrial;
]

/ ontrialend = [
    values.effectiveBlankPeriod = 1600 + (2100 - trial.POSO_posBG_shrt_ITI_1pt6.latency);
]
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ posttrialpause = 1600
/ trialduration = 4800
/ responseinterrupt=frames
</trial>
[/code]

RE: Posttrialpause setup

Libra — Thu, 13 Apr 2023 01:15:08 GMT

Awesome! Thank you so much for helping!

Posttrialpause setup

Libra — Thu, 13 Apr 2023 01:15:08 GMT

Hi,
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!

RE: Posttrialpause setup

Libra — Thu, 13 Apr 2023 00:36:32 GMT

Hi Dave,
Thank you so much! this makes a lot of sense. It seems that /trialduration is exactly what I would want.
"/trialduration Specifies the absolute duration of a trial, from beginning to end, including the posttrialpause. If the subject responds quickly, the posttrialpause interval is lengthened to fill out the remaining time in the duration. If the subject does not respond before the duration, the trial is terminated and the next trial begins."

I updated my trial to be like this.

<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
/ trialduration = 4800
/ responseinterrupt=frames
/ posttrialpause = 1600
</trial>

Could I check my understanding with you? Please bear with me, just want to make sure!
In this trial, the maximum span for poso_goodtarget to be presented on the screen is from 1100 to 3200 (4800-1600) from trial onset (and this happens if participants do not make a response). If participants respond, say at 1200ms from trial onset, the latency of this trial will be 100ms. A blank screen immediately starts when participants make the response at 1200ms. So from 1200 to 4800 of this trial, participants will continue to see the blank screen. Then, the next trial begins.

Ideally, I would want to verify this with saved data. Right now a single trial's data tells me the latency, each stimulus onset, and the fixed posttrialpause (for this trial, always 1600ms). So I can't make sure that the entire trial is absolutely 4800ms, no matter how fast participants make a response and whether they make a response or not. Is there a way to save the total block time in the data file? Essentially, if a block only contains trials like these, then the total block duration should be the same for each monkey run. [I tried block.name.timestamp] but it only seems to record the block starting time, right?

Thank you again!

RE: Posttrialpause setup

Dave — Wed, 12 Apr 2023 23:24:47 GMT

+x[quote]

[b]Libra - 4/12/2023[/b]
Hi,
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!

[/quote]

> 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.htm

With 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.