In order for DMDX to do this it buffers all responses made between the last time the job state switched from recording a response (ie a response was made or timed out) and the frame that has <cco> in it and in order for it to do that it needs a buffer to store those responses so DMDX uses the <ZillionResponses> parameter for this purpose. Should you need to increase this (it's default value is 100 so it's not likely) but you want <AzkiiResponses> you'll have to use <zil N> and then override <zil> with <azk> again.
<cco>
functions a little differently with
<LookingTime> as of version
5.1.4.0 where in addtion to buffering key presses between items it also carries
all the previous item's keystrokes over to the <cco>
item so looking times can be calculated across items. RTs will be negative
relative the time of the current <cco> (you can
continue across any number of items). Use of the
<AbortItemExpression> also
requires special attention when combined with <lt>
and <cco>, see the
<LookingTime>
documentation.
NOTE: It is intended that
<cco> be used after an
initial regular clock on (*
or <co>). While
there may be instances where it functions there are definitely others (like in
conjunction with <LookingTime>)
where it does not and will produce unintended consequences (like an item never
finishing).
There are several caveats to the use of this keyword:
The simplest use of <cco> is simply when you want to collect two responses in a regular <azk> experiment and you want the display to remain the same. Here none of the complicated timing issues need be addressed, the second RT will simply be measured from whenever the first RT was made:
<ep> f30 <ID "keyboard"> <cr> <nfb>
s1 g2 <vm
desktop> <eop>
$ 0 "Press SPACE to BEGIN" ; $
+10 "target" <co> ;
+11 !
<cco> ;
+20 "target" <co> ;
+21 ! <cco> ;
$ 0 "the end"; $
For a more complicated example with changing display issues (which is really what <cco> was designed for) we want a display that counts down to zero as a subject is responding, however if they do respond we don't want it to keep counting down but to instead bail out. Beyond having to have a custom feedback routine (see <Branch>) we need to have care when setting the timeout so DMDX can schedule and display the next item without display errors. So while the ISI is set to a total of 60 ticks (59 + 1 tick to display the number) the timeout has to end some time before that 60 ticks so DMDX can process the next item. So the first item has a 750 millisecond timeout, but because <cco> continues from the time the last item timed out at each of the successive timeouts needs to be the full 1000 milliseconds (the last one should really be 250 milliseconds longer still to allow RTs at the very end but I'm not covering that). A response to item 2 shorter than 250 milliseconds still had the display of item 1 on the screen. Each item will need to decide to continue on to the next one, unfortunately I couldn't come up with an elegant way to do this, either each branch needs to know the next item's number (the solution I chose) or stub items need to used after each item (similar to the branch to 9999 to skip the feedback items). Note that item 998 can test against -1000 for a timed out response as the only time -750 will be a timed out response will be when the item file continues on to item 2 and not when it goes to the feedback routine.
<ep> <delay 59> f30 <ID "keyboard"> <cr> <nfb> <vm
800,600,600,16,60> <eop>
0 "Press SPACE to BEGIN" <bu 9999>;
~999 <bi 998,
lastxt .lt. 0>;
995 "correct" / <return>;
~998 <bi 992, lastxt .eq.
-1000>;
991 "incorrect" / <return>;
992 "too long" / <return>;
~9999;
+1 <t 750> "3" <co> <mwb binr,2 bu,9>;
+2 <t 1000> "2" <cco> <mwb binr,3
bu,9>;
+3 <t 1000> "1" <cco> <mwb binr,4 bu,9>;
+4 <t 1000> "0" <cco>;
~9 <call 999>;
+10 <t 750> "3" <co> <mwb binr,20 bu,9>;
+20 <t 1000> "2" <cco>
<mwb binr,30 bu,9>;
+30 <t 1000> "1" <cco> <mwb binr,40 bu,9>;
+40 <t
1000> "0" <cco>;
~9 <call 999>;
0 "the end";
A slightly simpler example with simpler branching (because there is no right or wrong response) is to use time as a indicator of strength of response where we grow a bar across the screen, the longer the subject waits to respond the longer the bar and the stronger their sensation.
<ep> <nfb> <delay 6> <cr>
<vm desktop> <id
keyboard> <eop>
0 "Press SPACE to BEGIN";
200 "instruction" %53 /
!;
+201 "photo" %600 / <timeout 400> *
@-1 "weak strong" , "- " %23 / ! <bic
290>;
+202 <cco> <timeout 500> @-1 "weak strong" , "-- " %23 / ! <bic 290>;
+203 <cco> <timeout 500> @-1 "weak strong" , "---- " %23 / ! <bic 290>;
+204
<cco> <timeout 500> @-1 "weak strong" , "------ " %23 / ! <bic 290>;
+205 <cco>
<timeout 500> @-1 "weak strong" , "-------- " %23 / ! <bic 290>;
+206 <cco>
<timeout 500> @-1 "weak strong" , "---------- " %23 / ! <bic 290>;
+207 <cco>
<timeout 500> @-1 "weak strong" , "------------- " %23 / ! <bic 290>;
+208 <cco>
<timeout 500> @-1 "weak strong" , "----------------" %23 / !;
290 %233
"relax" /!;
300 "instruction" %53 / !;
+301 "photo" %600 / <timeout
400> *
@-1 "weak strong" , "- " %23 / ! <bic 290>;
+302 <cco> <timeout 500>
@-1 "weak strong" , "-- " %23 / ! <bic 290>;
+303 <cco> <timeout 500> @-1
"weak strong" , "---- " %23 / ! <bic 290>;
+304 <cco> <timeout 500> @-1 "weak
strong" , "------ " %23 / ! <bic 290>;
+305 <cco> <timeout 500> @-1 "weak
strong" , "-------- " %23 / ! <bic 290>;
+306 <cco> <timeout 500> @-1 "weak
strong" , "---------- " %23 / ! <bic 290>;
+307 <cco> <timeout 500> @-1 "weak
strong" , "------------- " %23 / ! <bic 290>;
+308 <cco> <timeout 500> @-1
"weak strong" , "----------------" %23 / !;
290 %233 "relax" /!;
With the addition of the <AbortDQPurge> keyword this sort of item file becomes substantially simpler (assuming <AbortDQPurge> is a safe thing to use and I'm by no means guaranteeing that).
If you're scrambling the items it can be a challenge to have the first item be a normal clock on and and the following ones be continue clock on however macros can be used to automatically handle that by using a macro in every item (say ~.clockon.) and in the initial instructions at the start of the item file setting that macro to <co> (so m.clockon.+<co>+) and then all the items that record a response set that macro to <cco> for the next item if they're the first item (otherwise they're just setting it to what it's already set to) in addition to using it (so ~.clockon. m.clockon.+<cco>+).
<ep> <nfb> <zil> <cr> s1
<vm desktop> <id
keyboard> <eop>
$
0 "Free form responses" @-1 , "Press SPACE to BEGIN"
m.clockon.+<co>+;
$
+202 ~.clockon. m.clockon.+<cco>+ "any";
+203
~.clockon. m.clockon.+<cco>+ "given";
+204 ~.clockon. m.clockon.+<cco>+
"day";
$
0 "the end";
$
If you wanted to keep repeating an item till the subject got it right you can do so with some branching on a wrong response and a macro from the above example. Seeing as I don't want to use unique item numbers for the branch destinations we also need to turn on branching backwards to the most recent occurrence of an item with <bb2mr>:
<ep> <cr> <bb2mr>
<vm desktop> <id keyboard> <eop>
~1 m.co.+<co>+ ; ! initial clock on will be the usual
clock on;
~2 ; ! a branch target item so we
don't have to code the branches up for each item;
+5555 "target" ~.co. ;
! item using the macro .co. for a clock on;
~3 <biw -2> m.co.+<cco>+
; ! from now on this
item will continue the clock on if we branch backwards on a wrong response to
repeat it;
~1 m.co.+<co>+ ;
~2 ;
+6666 "target" ~.co. ;
~3 <biw -2> m.co.+<cco>+ ;
~1 m.co.+<co>+ ;
~2 ;
+7777
"target" ~.co. ;
~3 <biw -2> m.co.+<cco>+ ;
0 "the end";