DmDX help, ZillionOneResponseKeyword

DMDX Help.

Zillion One Response Keyword

<ZillionOneResponse [N]>
<zor [N]>

MDSP bit 10000 modifier, the bit that makes zillion responses only take a single response out of many possible. Reset if N = 0, otherwise set. All MDSP modifiers are both parameters and switches. If N is missing the bit is set and the mode is active. For a discussion on running rating tasks see the Rating Section in the built in introduction (simpler multiple responses are covered in the the 1 of N Responses section).

This is implemented for ratings, the individual ratings keys should be specifically mapped with <ValidZillionKey>.

If a one of many response scheme is to be setup where one (or more) response(s) is correct and the others are wrong then <MapNegativeResponse> and <MapPositiveResponse> will have to be used in conjunction with <UnMapNegativeResponse> and <UnMapPositiveResponse> to correctly identify to DMDX what are the correct keys are for any given item.
For example, assuming we have one of three numeric responses at the beginning of the item file you'll want to specify all the possible keys:

<zil> <zor> <vzk +1> <vzk +2> <vzk +3>

You won't need to map the spacebar as a valid zillion key so the request can get through, it is handled automatically. Then whenever the correct response changes you'll want to clear any mappings with <umnr> and <umpr> and remap which key is correct, if say the 1 key is correct you'll need <mpr +1> and all the negative ones <mnr +2> and <mnr +3>:

+1 <umnr><umpr><mpr +1><mnr +2><mnr +3> * "one two or three?";

This could get tedious if you have a large number of responses so macros are a good solution, however having just thought about this you'll have to use the old format for macro definitions, I don't think you can have keywords embeddable within a keyword as of version 1.1.10. You can use the old syntax for a macro definition though:

m1=<umnr><umpr><mpr +1><mnr +2><mnr +3>=
m2=<umnr><umpr><mpr +2><mnr +1><mnr +3>=
m3=<umnr><umpr><mpr +3><mnr +2><mnr +1>=

The items then become:

+1 ~1 * "one two or three?";

NOTE:- If you are going to disallow one button from one trial to the next it is not sufficient is merely unmap it with <umpr> or <umb> for example. You have to invalidate it with <InvalidateZillionKey> and then validate it again when it's wanted to be used with <vzk>. The problem comes about because <zor> operates at a lower level of input than the mapping keywords and once the <zor> code sees one response (ie one that's in the list of valid zillion keys), that's it, it's seen it's one response regardless of whether that key was mapped as a response or not and it's going to terminate the response phase of the trial. Removing the key from the list of valid zillion keys means the item will hang around until one of the desired responses is made. So whereas the technique when using an <azk> output file is to map and unmap buttons to switch them in and out as they are needed the technique using <zil> <zor> is to map the keys once with <mpr> and so on but then validate and invalidate them as they are needed. Assuming you're not toggling whether a given key is a positive response or a negative response of course in which case you'll need to both map and unmap and validate and invalidate...

Somebody wanted feedback on a rating based experiment so I came up with a couple of methods to do it. One of them doesn't involve using <zil> and <zor> and the other does.

The first rating solution is to use the standard response gathering mode but to bind all rating keys to the positive response and then call a subroutine based on the keystroke generating additional output by emitting a counter's value and also providing feedback based on the particular branch taken:

<ep> <nfb> F10 <id "keyboard">
<umpr> <umnr> <mpr +1><mpr +2><mpr +3><mpr +4><mpr +5><mpr +6>
<mpr +7><mpr +8><mpr +9><mpr +0> <eop>

0 "Rating Example" <bu 1000>
mC#<mwc +1,-101, +2,-102, +3,-103, +4,-104, +5,-105, +6,-106,
+7,-107, +8,-108, +9,-109, +0,-110, cinr,-100>#;

100 "No Response." <return>;
101 <set 1,1> <emit 1> d2 "1" <return>;
102 <set 1,2> <emit 1> d2 "2" <return>;
103 <set 1,3> <emit 1> d2 "3" <return>;
104 <set 1,4> <emit 1> d2 "4" <return>;
105 <set 1,5> <emit 1> d2 "5" <return>;
106 <set 1,6> <emit 1> d2 "6" <return>;
107 <set 1,7> <emit 1> d2 "7" <return>;
108 <set 1,8> <emit 1> d2 "8" <return>;
109 <set 1,9> <emit 1> d2 "9" <return>;
110 <set 1,10> <emit 1> d2 "10" <return>;

+1000 * "target" ~c c;
+1000 * "target" ~c c;

0 "end" l;

The second solution was to use the <zor> method of <zil> doing away with the counter shenanigans. All keys are still bound to the positive response so the output file doesn't have No Response all over the place:

<ep> <vm 1024 768 768 16 0> <nfb> F10 <id "keyboard">
<zil> <zor> <vzk +1><vzk +2><vzk +3><vzk +4><vzk +5><vzk +6>
<vzk +7><vzk +8><vzk +9><vzk +0>
<umpr> <umnr> <mpr +1><mpr +2><mpr +3><mpr +4><mpr +5><mpr +6>
<mpr +7><mpr +8><mpr +9><mpr +0> <eop>

0 "Rating Example" <bu 1000>
mC#<mwc +1,-101, +2,-102, +3,-103, +4,-104, +5,-105, +6,-106,
+7,-107, +8,-108, +9,-109, +0,-110, cinr,-100>#;

100 "No Response." <return>;
101 d2 "1" <return>;
102 d2 "2" <return>;
103 d2 "3" <return>;
104 d2 "4" <return>;
105 d2 "5" <return>;
106 d2 "6" <return>;
107 d2 "7" <return>;
108 d2 "8" <return>;
109 d2 "9" <return>;
110 d2 "10" <return>;

+1000 * "target" ~c c;
+1000 * "target" ~c c;

0 "end" l;

The next solution provides feedback as well allowing the subject to change their mind. The space is validated and invalidated as a zillion key so that the subject can't initially respond with a space but once they have made one rating can signal their intent to continue with a space. The feedback is additionally displayed on a separate line using the option to only clear behind the displayed text thus leaving the target on the screen:

<ep> <nfb> F10 <id "keyboard"> d-2
<zil> <zor> <vzk +1><vzk +2><vzk +3><vzk +4><vzk +5><vzk +6><vzk +7>
<vzk +8><vzk +9><vzk +0> <umpr> <umnr> <mpr +1><mpr +2><mpr +3><mpr +4>
<mpr +5><mpr +6><mpr +7><mpr +8><mpr +9><mpr +0> t4000 <eop>

0 "Rating Example with",
@1"Change of Rating allowed" <bu 1000>
mc#<izk +space> <mwc +1,-101, +2,-102, +3,-103, +4,-104, +5,-105,
+6,-106, +7,-107, +8,-108, +9,-109, +0,-110, cinr,-100>#
mr#<vzk +space> <mwb +1,-101, +2,-102, +3,-103, +4,-104, +5,-105,
+6,-106, +7,-107, +8,-108, +9,-109, +0,-110, +space,111, binr,112>#;

100 @2 <ocb> "No Response." <return>;
+101 @2 <ocb> "1" * ~r c;
+102 @2 <ocb> "2" * ~r c;
+103 @2 <ocb> "3" * ~r c;
+104 @2 <ocb> "4" * ~r c;
+105 @2 <ocb> "5" * ~r c;
+106 @2 <ocb> "6" * ~r c;
+107 @2 <ocb> "7" * ~r c;
+108 @2 <ocb> "8" * ~r c;
+109 @2 <ocb> "9" * ~r c;
+110 @2 <ocb> "0" * ~r c;
~111 <return>;
112 <return>;

+1000 * "target1" ~c c;
+1000 * "target2" ~c c;

0 "end" l;

This is a stroop task variant of the second example with a five minute timeout, you'll want to duplicate items 1001 to 4004 enough times such that no one can do them all in five minutes. numpad 4 = blue, 5 = green, 6 = red, enter = yellow.

<mpr "+numpad 4"> <mpr "+numpad 5"> <mpr "+numpad 6"> <mpr "+numpad enter">
<eop>
$
0 "Stroop Example" <bu 1000> ;

100 d2 "No Response." <emit No Response> <bi 999, millisectime .gt. 300000> <return>;
101 d2 "Correct" <emit Correct> <bi 999, millisectime .gt. 300000> <return>;
102 d2 "Wrong" <emit Wrong> <bi 999, millisectime .gt. 300000> <return>;

~1000; $

+1001 * "blue"

<mwc "+numpad 4",-101, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+1002 * "blue"

<mwc "+numpad 4",-102, "+numpad 5",-101, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+1003 * "blue"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-101, "+numpad enter",-102, cinr,-100>;
+1004 * "blue"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-101, cinr,-100>;

+2001 * "green"

<mwc "+numpad 4",-101, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+2002 * "green"

<mwc "+numpad 4",-102, "+numpad 5",-101, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+2003 * "green"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-101, "+numpad enter",-102, cinr,-100>;
+2004 * "green"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-101, cinr,-100>;

+3001 * "red"

<mwc "+numpad 4",-101, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+3002 * "red"

<mwc "+numpad 4",-102, "+numpad 5",-101, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+3003 * "red"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-101, "+numpad enter",-102, cinr,-100>;
+3004 * "red"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-101, cinr,-100>;

+4001 * "yellow"

<mwc "+numpad 4",-101, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+4002 * "yellow"

<mwc "+numpad 4",-102, "+numpad 5",-101, "+numpad 6",-102, "+numpad enter",-102, cinr,-100>;
+4003 * "yellow"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-101, "+numpad enter",-102, cinr,-100>;
+4004 * "yellow"

<mwc "+numpad 4",-102, "+numpad 5",-102, "+numpad 6",-102, "+numpad enter",-101, cinr,-100>;

$
999 "end" l;$

This variant of the previous stroop task uses more normal sorts of Dmastr feedback (in fact it doesn't even have to be a <zil> <zor> item file at all) and data mechanisms and the macro mechanism referenced earlier:

<vzk "+numpad 4"> <vzk "+numpad 5"> <vzk "+numpad 6"> <vzk "+numpad enter"> <eop>
$
0 "Stroop Example"
m1# <umpr> <umnr>

<mnr "+numpad 4"> <mnr "+numpad 5"> <mnr "+numpad 6"> <mpr "+numpad enter"> <bi 999, millisectime .gt. 300000>#; $

+1001 * "blue" ~1;
+1002 * "blue" ~2;
+1003 * "blue" ~3;
+1004 * "blue" ~4;

+2001 * "green" ~1;
+2002 * "green" ~2;
+2003 * "green" ~3;
+2004 * "green" ~4;

+3001 * "red" ~1;
+3002 * "red" ~2;
+3003 * "red" ~3;
+3004 * "red" ~4;

+4001 * "yellow" ~1;
+4002 * "yellow" ~2;
+4003 * "yellow" ~3;
+4004 * "yellow" ~4;

$
999 "end" l;$

DMDX Index.