DMDX Help.


Continue Clock On Keyword

<ContinueClockOn>
<cco>


    * switch alternative.  For more discussion on the uses of <ContinueClockOn> see the Multiple Responses section in the built in introduction.

    <ContinueClockOn> turns subject RT clock on from the time the last response was made or the last response was timed out.  Responses will not be processed till the frame with the
<cco> in it is displayed however the response times will be back dated correctly the time the original clock on (or most recent <cco>) was timed out at.  Use of this keyword enables DMDX to have a changing display contingent on a subjects lack of response or a continuing chain of responses without the possibility of DMDX missing any responses between items as would happen if this was attempted prior to version 3.2.1.0 when this keyword was introduced.  In DMDX the only places you can make decisions are between items, it's not feasible to conditionally display frames (I spent quite some time looking at this option however since <cco> was added the <AbortDQPurge> functionality has been added and it allows much of what <cco> was designed for and then some, it's just a very dangerous keyword to use...) so the alternative is to have DMDX not loose input signals between items which <cco> does.

    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";

 




DMDX Index.