Tasks
Masking | Fixation point | Same-different Matching | Cross-Modal Priming |
Go-NoGo Display | Naming Time | Response-contingent display |
Problems
Item Count Not Zero | Multi-Line Instructions | Scrambling with Two Tasks |
Special Techniques
Incremental Display | Getting Faster Refresh Rates | Continuous Running | Use of Macros |
Rapid Display of Graphics Images | Acoustic Stimuli |
The following are some examples of how the preceding features can be used to generate displays of different types.
Insert a frame such as /"####"/ or /"&&&&"/ or /"$$$$"/ as either a forward or a backward mask. For example:
+25 "####"/*"dog"/"####"/;
Random dot masks can also be used as bit-mapped graphics images. E.g.,
+25 g"mask1.img"/*"dog"/g"mask2.img"/;
A small set of random dot masks is provided in the utilities package. Note that in the examples above, the duration of each of the three frames is the same, i.e., we are using the default frame duration. If we wanted, say, the middle frame to be displayed for a briefer period, such as 6 ticks, then the frame should be written as:
+25 g"mask1.img"/ %6 *"dog"/g"mask2.img"/;
There are a number of ways to specify a fixation point that comes on just prior to the target item. One procedure is to present a "." in the center of the screen, e.g.:
+1 "."/ *"above"/;
This has the disadvantage of forcing fixation in the center of every word. An alternative is to indicate whereabouts on the screen the target will be occurring, as in:
+1 "< >"/ * "above"/;
Sometimes we want the prior signal to act as a warning signal, and to remain on the screen while the target is being displayed. This is especially true when the target item is preceded by a list of irrelevant context words. There are two ways to do this.
+001 "house"/"old"/"soon"/"< >"/ *"< above >"/;
In this case, we repeat the warning signal with the target word inserted. Another way to get the same effect is to use the non-erase symbol:
+001 "house"/"old"/"soon"/"< >"/ * !"above" /;
If you wish to have both stimuli presented simultaneously, and on the same line, then the item can be coded thus:
+1 *"DOG DOG"/ ;
If you wish to have the stimuli on two different lines, but displayed simultaneously, then set up the item thus:
+1 %0 "DOG" / *@1 "DOG"/ E;
This will produce the following display:
DOG
DOG
with line 2 being displayed at the same time as line 1.
A delay can be introduced if %0 is replaced by, say %10, which will introduce a delay of 10 ticks.
Note that when you use both lines, you need to erase both. The special erase symbol E erases the display area for that job. The alternative would be:
+1 %0 "DOG" / *@1 "DOG"/ %0 /@1;
The third frame is blank, and hence erases line 1 of the display. The fourth frame is scheduled at the same time (because of the "%0"), and is also blank, but it erases the first line down.
After the last item has been presented, you must have a terminating instruction. This tells the subject he is finished, but more important, it lets the experimenter know as well. If you notice on the display that your subject is not requesting any more items, then you need to know whether all the items have been displayed. If you have an instruction as last item, then this will remain on the screen until the experimenter stops the job.
This frame must include the last-frame switch "L".
0 L"THAT IS THE END. THANK YOU.";
Selecting option-code 20 for the value of the MDSP word selects this option. The next frame is displayed only when the subject responds, or when the deadline for responding has expired, unless an individual frame-timer (%n) has been included in the frame, in which case the next frame will automatically be displayed no matter what the subject does.
Response-contingent frames normally require a correct-response indicator to be specified for each frame (see sect. 2.3.1). If no correct-response indicator is included in the frame, then DM will take any response as being correct, and will not store any RT for that item. The clock-on symbol ('*') is assumed, and need not be specified.
An example of an RC item is as follows:
+100 "The"/"dog"/+"went"/"to"/"the"/-"splode"/ ;
The first frame would be presented on the normal request, but the second would be delayed until a response (any response) was received. Any response will do because no correct-response indicator was included in this frame. Also no RT will be stored. The same is true for the second, fourth and fifth frames. However RTs would be measured and stored for the frames containing "went" and "splode" because they have CR indicators. The correct response would be positive for the first, and negative for the second.
Note: the item id is automatically incremented each time a RT is stored. In the above example, the RT for went would be stored under the item number 100. For splode, the item number would be 101. Hence it is not necessary to insert a new item number for each frame. However, users must take this into account when selecting the initial item number. For example, if the next item in the series was given an ID of 101, then the RT for splode would be overwritten. There is no limit to the number of RTs that can be obtained within a single item.
If you wish parts of the display to be normal and others response contingent, you can modify the MDSP word on-line. For example, suppose you want RSVP on the first five frames, but you want the target item (the second last frame) to remain on the screen until the subject responds. The correct procedure is as follows:
+100 &0/"The"/"dog"/"went"/"to"/"the"/&20/-*"splode"/ ;
The first occurrence of & sets the MDSP word to zero and the frame duration is controlled by FD. The second occurrence of & sets the MDSP word to 20 prior to the scheduling of splode and prevents the erase frame from being scheduled until a response is received. Note: the change to the value of MDSP does not take effect until the following frame.
If a frame time is specified (%), the next frame is scheduled at the desired time without waiting for a response. So, to take the case mentioned above, the same effect could have been achieved by inserting a value such as %5 in each frame except for "splode" (assuming that the response-contingent bit had already been set). This would effectively produce response contingent erasure only. E.g.:
+100 %5"The"/%5"dog"/%5"went"/%5"to"/%5"the"/-*"splode"/ ;
Useful tips: Suppress feedback with response contingent displays that involve several responses within the one item (as in the above example). The feedback simply delays the presentation of the next frame. Also, it is a good idea to set the DEL parameter to zero, so that the next frame is presented as soon as the subject responds. Otherwise, there is a noticeable gap, and the display feels very unresponsive. Also, subjects learn that they can press the key and still view the display.
DMASTR can be used for collecting RTs to acoustic stimuli as well as visual displays. For example, in a lexical decision experiment using spoken words rather than printed words, we can present the speech stimuli on a two-channel audio tape recorder, using the second channel to send a signal to DMASTR via the TAPE PULSE channel when each word begins. DMASTR can then record the response and store the RT. In this mode, DMASTR is used just for collecting the RTs, not for display.
To do this, we record the speech stimuli on one channel, and we record a pulse on the other channel at or near the beginning of each stimulus. The speech channel goes to the subject's headphones, while the other channel is plugged into a voiced-operated switch which in turn is connected to the TAPE-PULSE input line on the MetraByte PIO card (see Technical Notes, Appendix A).
In this situation, the experiment is no longer self-paced. The TAPE PULSE now acts as the equivalent of the request normally provided by the footswitch, i.e., it initiates a trial.
To get DMASTR to pay attention to the TAPE-PULSE, we need to set the method-of-input parameter 'K' to 16 which enables the positive and negative response buttons and the TAPE PULSE, but disables the footswitch and the VOX input for vocal naming.
Since there is no visual display, there is nothing to time the onset of the target stimulus from, except the tape pulse itself. Setting option #40 in the MDSP word (see sec. 3.1f) has the effect that the clock is read when the tape pulse is detected. DMASTR now expects a response, and calculates the RT when this occurs in the normal way.
If the pulse is not exactly aligned with the onset of the speech signal (due to equipment limitations, say), then the observed reaction time will be an overestimate, and hence a correction factor is required. If we measure the timing error for each item, then we can correct the RT by the approriate amount by using the RT Correction Factor switch (R) described in sec. 3.1n.
Although in this mode nothing appears on the subject's display screen, it is still necessary to have an item file. Basically, all this does is to inform DMASTR what the item numbers for the successive speech stimuli are.
Hence, of course, the order of the item numbers in the item file must correspond to the order of the items on the tape. However, the item file must still contain CLOCKON ("*") symbols to switch DMASTR into the correct state, as shown in the following example:
m40 n5 k16
+001 *;
-002 *;
+003 *;
+004 *;
-005 *;
0 L"That's the end. Thank you.";
If you wish to have instructions displayed to subjects on the display screen, then you need to make sure that you include pulses on your audio tape that will initiate these displays. Alternatively, you could remove the 'k' parameter and insert a 'k' switch after the instructions end, so that the footswitch can be used for the instructions. For example:
m40 n5
000 "Respond to the word you hear";
000 k16;
+001 *;
-002 *;
etc.
Once a tape pulse has been received, any subsequent pulse will be ignored if it is received before the subject has responded, or before the visual display has been completed, or before the feedback has been displayed and the next item retrieved. This protects against spurious glitches on the tape to some degree. Further protection can be provided by including a frame in the item (which might be blank) which has a duration that lasts until just before the next acoustic stimulus is due.
An even better method to protect against spurious pulses is to use the double-pulse option (see sect. 3.2i), by setting bit #400 of the MDSP word. Under these conditions, a tape-pulse will not be recognized unless two pulses are detected 200+/-10 ms apart (onset to onset). Of course, to use this facility, you need to have the equipment to place such a pulse on the tape.
Problems with Acoustic stimuli.
When subjects are responding to an acoustic stimulus, DMASTR is instructed to time the response from the time that a TAPEPULSE is received, not from the onset of a frame with a CLOCKON symbol ('*'). This option is selected by setting bit #40 of the MDSP word. The reason for this is that the subject is responding to an acoustic event, not a visual event, and hence no visual display is required (unlike, say, cross-modal priming). However, in actual fact, an item containing a null frame with a CLOCKON symbol is still required to inform DMASTR of the item number and the correct response. The CLOCKON symbol is retained because this input switches DMASTR into the state of 'expecting a response'.
An unexpected consequence of this procedure is that DMASTR will still take account of the value assigned to the delay parameter ('d'), which specifies the delay between the request (in this case, the TAPEPULSE) and the beginning of the visual display. The way that the 'd' parameter is taken into account is that DMASTR will ignore any response that occurs before this delay has expired. If no value for 'd' is specified in the parameter line, a default value of 20 ticks is assigned, and this means that DMASTR will ignore any response that occurs before 20 ticks have elapsed. This means that reaction times faster than 320 ms (on a 60 hz display) will be ignored.
The upshot is that a short duration of, say, 6 ticks should be specified for 'd' when bit #40 of the MDSP word is set.
VoiceMaster Software.
A much more efficient procedure for recording responses to speech stimuli is to use the new program 'VDMTG'. This program allows for both graphics and audio signals, and makes it unnecessary to transfer speech files to tape, with pulses recorded on the second channel to trigger a VOX, which then provides a request to DM/DMTG. 'VDMTG' requires a Data Translation 2821 board, and uses the drivers written by John Mertus of Brown University, and the associated BLISS speech editing system.
In some auditory experiments (e.g., cross-modal priming), a visual signal is presented for a response while the subject is listening to an acoustic stimulus. The difference between this situation and the previous situation is that the subject responds to the visually presented display, not the acoustic stimulus, which here merely acts as a context.
In this case, the visual display specified in the ITM file is triggered by a tape-pulse which occurs during the acoustic input, and is treated in exactly the same way as a normal request. Since this technique is designed to study the extent to which the subject's response to the visual probe is influenced by what they are hearing, it is important for the visual display to be precisely synchronized with the acoustic signal. This means that the visual probe must commence at some precisely-controlled time after the request. Hence, bit #100 of the MDSP word should be set (the exact request-display delay option). This will guarantee that the time interval between the request and the onset of the visual display will be the same as the value specified for the parameter "DEL" (specified either by setting the DEL parameter in the parameter line, or individually for each item using the DEL switch). If this bit is not set, then the delay is only approximately equal to this parameter, and will vary depending on how busy the system happens to be.
The danger with this option is that by the time DMASTR gets around to scheduling your display, so much time may have elapsed since the request occurred (again, dependent on how busy DMASTR happens to be), that it is impossible to get the display up by the requested time. If this happens, DMASTR will print a warning message on the screen, but the item will not be displayed and no reaction time will be recorded for that item. Current experience suggests that the minimum time that DMASTR can reliably cope with (no matter how busy it is) is 2 ticks (i.e. 40 msec). So, the request signal should occur at least 40 msec before the visual display is required.
So, if you wished a visual item to be displayed at the same time as a particular word in a spoken sentence, place a tape pulse at least 40 msec before the onset of the word. The tape should then be examined to determine the actual asynchronies precisely, and the appropriate request-target onset asynchrony for each item should then be specified by the D switch for each item separately.
Once again, as for the acoustic experiment described in the previous section, one can use the double tape pulse option to minimize the possibility of a spurious tape pulse (bit #400 of the MDSP word -- see sec. 3.2i), and one could also set the input enable/switch switch 'K' to 16 to filter out any spurious requests generated by accidental presses of the footswitch, once the instructions have been completed.
Thus an item file for a cross-modal priming experiment might look something like the following:
n5 m500 f30
000 "instructions ...";
000 k16;
+001 d4 *"house"/;
+002 d7 *"fish"/;
etc.
The output from the microphone in the subject testing booth must be fed to a voice-operated switch which is in turn connected to the VOX input line on the MetraByte PIO board (see Technical Notes, Appendix A). To get DMASTR to attend to this input (and to ignore the input from the response buttons), the 'K' parameter needs to be set to 21. In addition, all items must have a positive correct response indicator.
Additional options that might be considered are as follows:
(i) set the lower cutoff limit in your DATA file to, say 200 msec (see section 4). This reduces the chance of getting spuriously fast responses due to accidental triggering of the voice switch, or to the fact that in a multi-frame item where the subject must respond to the last frame, the subject may respond before the frame commences. Since his vocalization may well continue into the critical frame, you will get a very fast response.
(ii) Change the feedback messages to avoid "Correct" and "Wrong".
So an item file for naming might look like this:
n2 k21 f30
000 "Say each word as quickly as you can.";
000 fc=Ok= fw== ft=Speak louder= "Begin now";
+001 *"doctor"/;
+002 *"house"/;
etc.
Especially with long files, it may become tiresome for the subject to have to request each new item with a separate press of the footswitch. Selecting option #10 of the MDSP word will mean that a request will initiate a series of items, which will continue until an instruction (item number=0) is reached. A new footpress is then required to continue the experiment. The delay between items will be specified approximately by DEL. For example:
n200 m10 f30 d60
000 "Instructions";
+001 *"doctor"/; display continues after 60 ticks
+002 *"house"/; ditto
-003 *"flim"/; ditto
000 "instruction"; display stops until footpress received
+004 *"berate"/; display continues
etc.
Note that similar effects can be obtained by using the 'C' switch, except you need to include this switch whenever you want the display to continue to the next item automatically.
If it is important to control the inter-trial interval precisely, then you will also need to set bit #100 of the MDSP word, which specifies that an exact time interval between the assumed request (which occurs at the end of the item) and display onset is required, this interval being specified by the DEL parameter or switch.
This is used when individual elements of a construction are to be successively and incrementally displayed. This requires use of the absolute start position option (P). For example,
+1 P20"B"/"O"/"T"/"T"/"O"/"M"/ ;
This will display the word BOTTOM one letter at a time (only one letter visible at a time), but without superimposing each letter on top of previous one. The display begins 20 character spaces from the left of the screen.
If you wish each displayed letter to be retained, so that the display is B, BO, BOT, BOTT, BOTTO, BOTTOM, then include the non-erase symbol in each frame. For example,
+1 P20 "B"/!"O"/!"T"/!"T"/!"O"/!"M"/;
In this example, the "!" prevents the previous frame from being erased before the new one goes up.
Similar procedures applied to words rather than letters yields the word-by-word reading experiment, e.g.:
+1 p20 "The "/!"boy "/!"went "/!"home "/;
The only difference is the addition of a blank space at the end of each word to space the material correctly. The normal procedure here requires that a decision be made to each word, and that the display does not continue until the subject makes a response. This means that the display needs to be made response-contingent by setting bit #20 of the MDSP word. The item would now look like this:
1 p20 "The "/!+"boy "/!+"went "/!+"home "/;
No response would be recorded for the response to "The" (since no CR is specified), but responses to all other words would be recorded. Note also that feedback should be suppressed (since this disrupts the display), and a low value of DEL should be specified, so that the display responds rapidly.
Suppose you want the subject to respond only when when a certain type of item is presented (e.g., a positive response is required for words, but no response at all is required for nonwords). Set the correct response indicator for these items to '+' and tell the subject to press the positive button. For all other items, set the correct response indicator to '^' and tell the subject not to make any response to these items. For example:
+001 *"dog"/;
^002 *"voom"/;
^003 *"silch"/;
+004 *"house"/;
If any response occurs for items 002 or 003, the feedback message WRONG will appear. If no response occurs for these items, the message CORRECT appears after the time limit for a response has elapsed (normally 4 sec).
WARNING: These correct responses will be stored as +4000 (or whatever your time limit is). If you include these items in your DAT file for analysis, they will vastly increase the error variance. No solution to this problem is currently available.
Graphics image files are read from disk while the subject is deciding to press the request key, so it is essential to have these on a hard disk. These files are read into memory so that they can be rapidly copied into the video memory at the appropriate time. There is a limit of 20 on the number of images that can be displayed in any one item.
If DMTG is unable to keep up with the demands of the item, it will print warning messages on the experimenter's monitor, telling you which frames it was unable to display. To cope with this problem you could try to reduce the size of your image files (using EDTSCR to trim them, see Section 13) or increase the speed with which they can be read (by having them on a RAM disk). If neither of these procedures help, you will have to decrease the rate at which the images are being displayed.
This message is displayed when you attempt to stop a job using the 'S' command. The value of NITM (the number of items, specified on the parameter line) is decremented every time a reaction-time is stored (and is equal to the number of clock-on signals). If NITM is not zero when the end of the job is reached, this warning signal is printed. It usually means that the experimenter has left an item out, or left out an asterisk, or has not taken the practice items into account.
If NITM is positive when you attempt to stop the job, the error message "Job not finished" is displayed. This might be because of an error in counting the number of items, or it might mean that the subject did not finish the experiment.
In some applications, it would be useful to have the display ticks defined in multiples of, say 10 ms, rather than 16.6 ms. This can be arranged if you have a display monitor that can lock onto refresh rates faster than 60 hz. The Princeton Ultrasync is one such device, and will get down to refresh rates of around 6 ms.
This faster refresh rate is achieved by re-programming the CRT controller to display fewer lines than normal, hence the screen size is effectively reduced. The TIMEG program (see Sec. 13) allows you to explore various settings. When you have found the setting you need, use the 'L' parameter to change the number of lines in the display. Remember that you no longer have the whole screen available. Information at the top and bottom of the screen may be lost. This option is available in both DM and DMTG.
Normally, material that is displayed remains there until it has been erased. In DMTG, however, the feedback message automatically clears the screen. So, if you want to have something remain on the screen across items, then suppress all feedback (see sec. 3.2a).
Suppose you have a naming task followed by a lexical decision task, and you want the items to be scrambled. It is important obviously not to mix up items from the two halves of the experiment. The scramble routines will avoid doing this if the two halves are separated by a backslash. For example:
n100 f30 s16
$000 "Naming experiment.";$
+001 *"doctor"/;
etc.
+050 *"house"/; (last naming item)
\
000 "Lexical decision experiment";
+100 *"paper"/;
-101 *"gleap"/;
etc.
In single screen versions of DMTG, the experimenter's commands are echoed at the top of the screen. This is sometimes disconcerting to the subject, especially the message "Experiment Ready" which keeps reappearing.
One solution is to include an ERASE switch in the first item, which will erase the entire screen, e.g.,
n34 f50
000 E / "Welcome to this experiment...";
The corresponding problem in DM is that the prompt '>' stays on the screen. There seems to be no simple way of getting rid of this, short of taping over that segment of the screen.
In some applications, there are complex and lengthy sequences of switches that must be repeated over and over again within the item file, and sometimes within an item. This leads to very large item files, which are also very difficult to read.
One solution is to enter these sequences using the "find and replace" function in your editor. That is, you enter some dummy symbol when you first construct the item file, and then change all of these into the correct sequence before running the file. Another solution is to use the macro feature of DMASTR.
The macro symbol is defined using the 'm' switch. The syntax for this switch is:
m<symbol><text delimiter><macro definition><text delimiter>
For example:
!macro definition
000 mZ: %3 v7 "xxx"/ %3 v8 "---"/ : c;
This defines 'Z' to be equivalent to the text between the text delimiters (':'). The text-delimiter is user-defined (as in the definition of the feedback message). Note that the final 'c' moves the display onto the next item without a request.
Future items can then invoke this macro using the special macro execution switch '~'. E.g.,
+001 ~Z "monkey"/ ~Z "horse"/;
would get expanded out by DMASTR as:
+001 %3 v7 "xxx"/ %3 v8 "---"/ "monkey"/
%3 v7 "xxx"/ %3 v8"---"/ "horse"/;
Macros can be embedded within macros using '~~'. For example:
000 mX: "bumble bumble": c;
000 mZ+ %3 v7 "---"/ ~~X c;
This would have the effect of expanding ~Z out to:
%3 v7 "---"/ "bumble bumble"
A good example of the application of this device is the so-called "fade-into-view" technique, in which the target word is superimposed on a succession of random dot pattern masks, so that it gets gradually clearer.
Here is an example of such a sequence without macros:
+010 *"target"%0/!g-y132"m0"/"target"%0/!g-y132"m1"/"target"%0/!g
-y132"m2"/"target"%0/!g-y132"m3"/"target"%0/!g-
y132"m4"/"target"%0/!g-y132"m5";
The text "target" is first superimposed on a graphics image contained in the file "m0.img", then "m1.img", etc., through to "m5.img". Each of these image files is a random dot mask. To condense this, we first write a general macro, and then a specific one that correponds to the target word. The general macro has this form:
!general macro definition
000 mZ: * ~~t %0/!g-y132"m0"/ ~~t %0/!g-y132"m1"/
~~t %0/!g-y132"m2"/ ~~t %0/!g-y132"m3"
~~t %0/!g-y132"m4"/ ~~t %0/!g-y132"m5" : ;
The symbol '~~t' refers to the macro symbol 't', which is then defined as the target word. We can thus present a series of words embedded within this structure, as follows:
000 mt:"target": c;
+001 ~Z;
000 mt:"house": c;
+002 ~Z;
+003 mt:"doctor": ~Z;
We first define the 't' macro, which has already been included within the 'Z' macro, and then we invoke the 'Z' macro.
Note: A macro symbol must be defined before the first occurrence of this symbol in an item. That is, it cannot be defined in the same item that it is first used in.
Note that if you have a very complex and tedious sequence of commands that gets repeated over and over, you can define your own set of macros to simplify coding. One such example is in DM, where there is no easy way of erasing a large chunk of the screen ('E' works only for lines @-1, @0 and @1).
The commands for erasing, say, 11 lines, would be:
000 %0 @-5/%0 @-4/%0 @-3/%0 @-2/%0 @-1/
%0 /%0 @1/%0 @2/%0 @3/%0 @4/ @5;
You can make this simpler by including the following at the beginning of your item file:
! macro definitions ;
! macro for erasing screen in DM ;
000 mE:%0 @-5/%0 @-4/%0 @-3/%0 @-2/%0 @-1/
%0 /%0 @1/%0 @2/%0 @3/%0 @4/ @5: c;
This macro can then be invoked by including '~E' in your item file wherever 'E' would have been appropriate. So, for example, after a multi-line sequence of instructions, the next sequence could look like this:
000 ~E "new instructions...";
People run into trouble constantly when they want to present a whole screenful of instructions at once. For example:
000 %0 @-5 "In this experiment,"/ %0 @-4 "your task will be to" /
%0 @-3 "press the YES key" / %0 @-2 "whenever you see" .... etc.
Here are some tips that may make this easier.
(a) do NOT have '%0' in the last frame if you are running DMTG. Its scheduling procedure expects another frame. Remember, '%n' means: 'schedule the NEXT frame n ticks in the future'. Hence if you have '%0' in the last frame, there is the clear implication that another frame will follow. For some reason, DM isn't upset by this slight illogicality.
(b) split up the instruction into a series of separate instructions, with say, just two lines on each display.
(c) use a graphics package to design the screen just the way you want it, and then use SNAPSHOT and EDTSCR (see section xx) to prepare a single IMG file. You can then present your instructions far more simply. For example:
000 g "instr34";
This assumes a graphics file called 'instr34.img' which has a screen's worth of instructions in it.
(d) use the macro system described above to avoid making errors.