Replace No Response trials in DMDX: avoid missing data points

As experimenters, we often want the participant to respond to all trials. A non-response is a missing data point. Missing data points are not good. Therefore, non-responses are not good.

Here is a simple experiment in which participants have to respond to an item by pressing the shift keys:

<ep><fd 1><d 50><vm 800,600,600,8,60><dfs 36><dbc 210210210><cr><rcot><t 3000><id "keyboard"><s 4><g 2><cr><eop>
$
11111 "Beginning of the block" <ms% 1200>;
$
+1 "Item 1" <ms% 1200 > * ;
-2 "Item 2" <ms% 1200 > * ;
-3 "Item 3" <ms% 1200 > * ;
+4 "Item 4" <ms% 1200 > * ;
$
0 "THE END" l;
$

Long response window = no No Response trials = no missing data points
Lidija's solution to this problem was to give her participants a very long response window - for example, 30 seconds. This would be achieved by changing the value of <t N> (currently set for 3 seconds) in the header to 30000 (which is 30 seconds). This almost certainly eliminates the occurrence of No Response trials. However, how would you interpret a 10 second response? Did the participant remember what they heard/saw? Were they guessing? Was it a genuine response? It is very hard to say. You could hope for the best. But, in experiments, things usually go wrong rather than better than you had hoped for.

In order to avoid very long response times, it is often desirable to replace missing trials. This means that participants may only have a small response window, and that No Response trials are re-presented again and again until the participant makes a response.

The question then becomes: when will the No Response trial be re-presented?

Re-present a No Response trial immediately
In DMDX, it is very easy to re-present the last trial if a No Response was recorded. Simply add this code <binr N> to the end of an item before the semi-colon. Here is an example:
e.g. before +1"Item 1"<ms% 1200>*;
e.g. after +1"Item 1"<ms% 1200>*<binr 1>;

This will cause DMDX to loop back to item 1 over and over until the participant responds. You would add <binr 2> to the end of trial 2 and so forth. However, this technique has one major disadvantage: it will continuously present the No Response trial again and again in consecutive trials until the participant responds. The danger is that participants might figure out that they can see/hear the same trial again and again just by not responding. This is also not good.

Re-present a No Response trial at the end of a block of trials
A more useful option might be to re-present No Response trials at the end of a block of trials. Unfortuantely, re-presenting missed trials at the end of a block is very difficult in DMDX. However, I have figured out how to do it :) It is possible through the use of counters (a big thank you goes out to Arman for all of his advice and patience re: counters).

Think of it this way: In an experiment where participants respond by pressing either the left or right shift key, for every + trial, there are three possible outcomes:
left shift = Wrong
right shift = Correct
no response =  No Response

Note: for - trials, left shift would be Correct, right shift would be Wrong.

Create a counter for each response. This means you need (3 * no. of items per block) counters - in my case 3 * 4 = 12 counters. Counters are initialised using the <set cN> keyword. Now, we need keywords that will increment a counter depending on the participant's response.

<incic N> increments n when a Correct response is registered.
<incinr N> increments n when a No Response response is registered.
<inciw N> increments either when a Wrong response is registered, or when a No Response is registered. Note: this is very tricky. I only figured this out by looking in the DMDX help manual. Pay close attention to this sentence:

"In keeping with the precedent set by early branching code wrong responses include no responses."

So, No Response trials increment both <incinr n> and <inciw n> keywords. This is very important.

Lets run through the three possible outcomes and see how they affect the incrementing of the three counters for a trial. I have coloured the Correct counters blue, the Wrong counters red, and the No Response counters yellow.

So, if there's a Correct response in trial 1,
c11=1   c21=0   c31=0.
If the participant makes a Wrong response in trial 2,
c12=0   c22=1   c32=0.
If the participant makes a No Response in trial 3,
c13=0   c23=1   c33=1. This is because a No Response is counted by the <incinr n> and the <inciw n> keywords.

At the end of the block, we need to check if there were any No Response trials, using some fancy math:

999 <branchif 11111, (c11 + c12 + c13 + c14 + c21 + c22 + c23 + c24 - c31 - c32 - c33 - c34 .LT. 4)>;

The .LT. 4 means less than 4 - because I have 4 trials in this example, and want to check whether I have received 4 responses (either Correct or Wrong). If the result of the fancy math above is less than 4 (my number of trials), then it means that there was a No Response trial in this block, and the <branchif -11111 comes into effect, branching back to trial 11111 (at the start of the block).

Now that we have branched back to the beginning of the block, we need to add conditions to each trial to determine if it was a No Response trial on the previous attempt, in order to decide whether it should be re-presented. We insert this code before every trial:

999 <branchif 999, (c11 + c21 - c31 .GT. 0)>;

This line of code tests whether the previous response for the item below it was Correct, Wrong, or a No Response (using a scaled down, 1-item-only version of the fancy math from before). It will only re-present the trial below if the previous response was a No Response. Otherwise, it will skip to the next 999 trial, check what the previous response for the item below that line was and so on. In effect, it is re-presenting No Response trials at the end of the block, and it will continue presenting No Response trials until the participant makes a (Correct or Wrong) response. Note the counters will change for each item.

Any item lines that are not presenting stimuli may be preceded the skip display ~ indicator so they only take a fraction of a millisecond to execute.

Here is the finished code:

<ep><fd 1><d 50><vm 800,600,600,8,60><dfs 36><dbc 210210210><cr><rcot><t 3000><id "keyboard"><s 4><g 2><cr><eop>
$
~100 <set c11=0> <set c12=0> <set c13=0> <set c14=0> <set c21=0> <set c22=0> <set c23=0> <set c24=0> <set c31=0> <set c32=0> <set c33=0> <set c34=0>;
$
$
11111 "Beginning of the block" <ms% 1200>;
$
~999 <branchif 999, (c11 + c21 - c31 .GT. 0)>;
+1 "Item 1" <ms% 1200 > * <incic 11> <inciw 21> <incinr 31>;

~999  <branchif 999, (c12 + c22 - c32 .GT. 0)>;
-2 "Item 2" <ms% 1200 > * <incic 12> <inciw 22> <incinr 32>;

~999  <branchif 999, (c13 + c23 - c33 .GT. 0)>;
-3 "Item 3" <ms% 1200 > * <incic 13> <inciw 23> <incinr 33>;

~999  <branchif 999, (c14 + c24 - c34 .GT. 0)>;
+4 "Item 4" <ms% 1200 > * <incic 14> <inciw 24> <incinr 34>;

$
~999 <branchif 11111, (c11 + c12 + c13 + c14 + c21 + c22 + c23 + c24 - c31 - c32 - c33 - c34 .LT. 4)>;
$

$
0 "THE END" l;
$

Blogged with Flock