192013-08-05 18:22:53RussellThompson182013-08-05 18:21:41RussellThompson172013-08-05 18:16:38RussellThompson162013-08-05 18:16:07RussellThompson152013-08-05 18:11:05RussellThompson142013-08-05 18:05:08RussellThompson132013-08-05 17:56:46RussellThompson122013-08-05 17:53:41RussellThompson112013-08-05 17:51:23RussellThompson102013-08-05 17:48:30RussellThompson92013-08-05 17:45:25RussellThompson82013-08-05 17:36:42RussellThompson72013-08-05 17:35:33RussellThompson62013-08-05 17:33:35RussellThompson52013-08-05 17:30:48RussellThompson42013-08-05 17:28:54RussellThompson32013-08-05 17:24:59RussellThompson22013-08-05 17:03:42RussellThompson

This page has two purposes. It is designed to alert you to potential problems/bugs in DMDX (and hopefully offer at least suggestions of solutions) and to give definitions of terms that may not be familiar to you. Hopefully, the definitions given here will help you to decipher both the tutorial web site and the DMDX help files. Much of what is in this page has been copied and adapted from the original DMastr documentation. I am not a computer whizz, but have used DMDX and before that DMastr for quite a while so there will be things that seem obvious to me that a new user will not necessarily understand. Also, bugs are most often found when new designs are tried. I have got most of the designs I use working fine now, but you will obviously want to do different things and this is when bugs could be found. If you find something you don't understand, something that you think others will have problems with, or come across a bug, please get in touch withme or the DMDX listserve. The Parameters and Switches The 'f' parameter Frames Editor Problems ITI problem The Font Problem Versions The Play List Error Message Scrambling Feedback Errors and Error Messages

The first line at the top of your RTF control file is called the parameter line. This line sets up the basic structure of experiment, e.g. the number of items the colour of the screen, how long items are to be displayed etc. If you don't set values then DMDX assumes the default setting for the parameters. A control file will not run unless you assign values to certain parameters, which they are depends to a certain extent on what design you are using. You should think about what needs to be controlled in your experiment. Switches are used in the main body of the RTF control file and are used to set values for individual frames different from those set in the parameter line. If you look at the paired visual lexical decision experiment you can see that the frame duration for in the parameter line was set to 38 ticks but each prime has a switch <ms% 250> that sets the display for the prime to 250 ms. This is how we get the prime and target to be displayed for different times.

The 'f', frame duration parameter controls how long something is displayed on the screen. It is given in 'ticks' or 'screen refresh rates', which refer to how long it takes your computer to scan the whole of the screen from top to bottom, that is to say how long it takes to update the screen. This varies from machine to machine. It could be as low as 8 milliseconds or as high as say 17 milliseconds. So, 'f50' could be anywhere from 400 to 850 milliseconds depending on the machine. You will need to find this out what the refresh rate is for your machine. This can be done in TimeDX. If you go into TimeDX, click Refresh Rate and then on Do test, the screen should flicker and then the dialog box should reappear giving a value for the refresh rate. The refresh rate is partly dependent on the screen resolution you use. If you change the resolution (using Video Mode in TimeDX) then you will probably have changed the refresh rate. Return to Tutorial

An item is divided up into any number of "frames". The symbol indicating the boundary of a frame is "/". A self explanatory example: DMDX displays the sequence one frame at a time, with all characters within a single frame displayed simultaneously. The frame is by default automatically centered in the screen. Characters in the next frame will not be displayed until some later point in time. How each item is constructed depends on what kind of experiment you wish to run. Here a visual-visual priming experiment is described. The first thing in an item is the item number (followed by a space). Then comes the prime word. Any words/characters to be displayed should be enclosed in quotation marks. The prime is followed here by the end-of-frame marker, the back slash, a special symbol indicating which is the target frame (the frame that the subject must respond to) and finally, the end of the item symbol, a semi-colon (";"). The target frame is the frame that should be responded to by the subject, the frame to which the +/- symbol in front of the item number refers. The semi-colon, ";" indicates the end of the item. Note also that there is nothing between the final "/" and the ";". This is equivalent to a blank frame, as in: Since each frame erases the frame that came before it, this blank frame merely serves to erase the previous frame. Otherwise, "HOUSE" would remain on the screen until the subject requested the next item, because the frame duration in the parameter line in fact sets the time that the next frame is scheduled, as opposed to the actual duration of the frame. However, frames can de displayed on different lines. As each frame is displayed, any characters on the same line as this frame are normally erased before the new frame is displayed, but characters on different lines can remain. LINK TO MULTILINE DISPLAYS TO BE ADDED HERE Return to Tutorial

In the DMDX help files, it says...."When you have an RTF control word that DMDX is refusing to allow and you can't see a reason for it (a fairly common occurrence with Word 97) try retrieving the file in WordPad and saving it and then see if DMDX still refuses the control word -- most times I have seen this work and the file is even then editable with Word 97 without having to re-save it again in WordPad. Mind you, I have gone to some length to make the generic output from Word 97 work, however there always seems to be some little gem that I have yet to see, in Word's case it's more like a chest full of them." Problems have also been found with some versions of WordPad. If it is a minor edit you need to do, try opening the file in Notepad or perhaps better, the DOS Edit program, which unlike Notepad allows you to do multiple search and replace. However since both these editors display your file in the base Unicode in which any formatting such as text size and font is displayed as code words, these editors are difficult to work in. The first example RTF file on the tutorial page looks very different in Notepad or Edit. How I work is as follows, I start off by working in a spreadsheet because most lines of my DMDX control files are the same except for the words to be displayed/sound files to be played etc. I then copy this into a WordPad RTF file. Another way of working is in UNIX using vi or emacs to edit and then convert final version to DOS format with an RTF extension. Return to Tutorial

The D parameter and switch controls the inter trial interval, that is, the time from the time from the end of one command line to the start of the next. 1. 1. 1. 1. 1. 1. SKELVE"/; <--FROM HERE TO HERE--> +2*"GAME"/; +3*"BACON"/; The default delay is 48 ticks (about 560 ms, with a refresh of 11.7 ms), however, the delay is timed from the point at which the preparation of the next item is completed, so it is 48 ticks plus something. That means that inter item intervals can vary. However, within items timings do not vary. Precise control of this interval is possible only when REQ_SCHED is used. And, when I find out what that means I shall explain it. Return to Tutorial

Certain fonts cause problems for DMDX, they are not erased properly and stray pixels are left on the screen. The reason for this is that risers or tails of the fonts stray outside the square around the character that marks the usual maximum size of a font. One simple solution is to try a different font, a sans serif font such as Arial. Another solution, if the font character which is not erased properly is word initial, then try putting three spaces in front of it (and obviously at end of the word too, so that it is still centred). The letter 'j' is often a problem as is capital Q in certain fonts. The best solution is to use the "Over Size" parameter/switch designed by Jonathan to make sure there are no stray pixels left on the screen. It is written: ]]>]]>Where N is the extra percentage of the screen to the left, top, right and bottom of your word that you want to be erased. The default values are 2,0,5,5 and this should work for most standard fonts. Should you have an unusual font or a right to left font, e.g. Times New Roman Arabic you can customize the values even further with say 5,0,2,5. Here's a parameter line.... '''''']]>and here's it used as a switch for an item beginning with the letter 'J': ''' "JOLLY"/; +3 * "BACON"/;]]>Return to Tutorial

Remember to note down the versions of DMDX and Direct X that the experiment was run on and save copies of these if you want to be able to exactly replicate your experiment at a future date. If you try and run an old experiment on new software and it doesn't work right, how can you be 100% sure the old experiment wasn't flawed? Return to Tutorial

My, this one was fun. Couldn't for the life me work out this one to begin with. A perfectly good script with perfectly good sound files just wouldn't work. DMDX kept giving an error message about items in a "playlist" not found. Y'what? Well it turns out that this problem comes from putting your speech files into a 'play list' in CoolEdit. What you need to do in CoolEdit is for each file is go into View|Play List and remove all the file names from the list leaving just [End] in the list. I assume you may get similar problems with other sound/speech editors. I guess that by putting a file into a play list something is added to the file header and DMDX can't cope with this. Unfortunately there is no way of changing DMDX so that this problem can be avoided. Return to Tutorial

The logic of scrambling. A purely random ordering of the items does not guarantee an even distribution of conditions across the experiment. For example, by chance, you may have most of the items in one condition placed in the second half of the experiment, and most of the items in another condition placed in the first half. To circumvent this problem, DMDX first divides the item file up into a number of blocks of items, the size of this block being determined by the BLOCKSIZE parameter (see below). It then randomly orders the items within each block, and then finally randomly orders the blocks themselves. The scramble block size parameter and other scramble parameters are entered on the first line of the item file (the parameter line), along with the other DMDX parameters. If you arrange your item file so that the first block consists of an equal number of examples of each type of condition (instead of having all the instances of the first condition together at the beginning of the file), then you can be confident that extraneous serial effects (such as practice or fatigue) are more evenly distributed across conditions. This means that you have a pseudo-random order, not a random order. A further advantage of scrambling is that no two subjects are likely to receive precisely the same sequence of items. This is important, since a difficult item (on which an error is likely) may increase the reaction-time for the following item. If this is always the same item, then one has introduced a systematic error of measurement for that item. For this reason, it is preferable to scramble the items for each subject separately. Controlling the way DMDX scrambles. Item file scrambling is controlled by means of parameters entered at the top of the item file and $ and \ delimiters in the body of the file. Scramble parameters. These appear on the first line of an item file with the other DMDX parameters. Three parameters may be specified: BLOCKSIZE The number of items to be treated as a block. If this parameter is not specified the item file will not be scrambled. GROUPING The number of items to be treated as a group. Normally, this parameter is not specified, and defaults to 1. Suppose, however, the items are arranged as pairs on your item file, e.g., (1,2), (3,4), (5,6). If you wanted item 2 to always follow item 1, and item 4 to always follow item 3, etc., then this parameter should have the value 2. This means that DMDX will treat each successive pair of items as though they were a single item. Items in a pair will never be separated. Thus the eventual order of items might be: 5, 6, 3, 4, 1, 2. SEED The initial seed for the random number generator. Normally this parameter is not specified, and a different pseudo-random order is created each time the item file is scrambled. If a value is specified, the random number generator will always use that value as its initial seed and thus it will always produce the same pseudo- random order. $ Delimiters These allow some sections of the file to remain in a fixed absolute position within the file. Any material enclosed within a pair of $ symbols will not be scrambled, and the order of this segment relative to the rest of the file will remain constant. It is important to note that the scramble programs do not respect any of the internal conventions of an item file, except for the parameters on the first line and the item delimiter (;). Thus the task instructions, the practice items and the final end-of-experiment message will appear at unpredictable locations unless they are enclosed within $ delimiters. In the following example, the text in bold print will not be moved: $ '''0 "This is the instruction"; 0 "Here is the practice item"; =250 *"dog"/; 0 "End of practice";''' $ =1 *"house"/; =2 *"table"/; =3 *"cough"/; =4 *"cigarette"/; $ '''0 "End of experiment";''' $]]>This would generate an item sequence that might look like this: Note: When creating item files to run using scrambling, run/check them first without the scrambling. Scrambling requires preprocessing the file, so if there is an error in the syntax of a scrambled file, e.g. a clock on symbol missing somewhere, it simply fails on line one and does not give you informative error messages. Note: If you make a mistake and have a file like below where your number of items (7) is not a multiple of your Grouping parameter (2), then Item seven, "FOO" will not be displayed and there will not be an error message. That is, incomplete blocks are not displayed. ]]>

By default feedback is provided for subjects, telling them whether they responded correctly or not and their RT for that item. However, feedback is not always necessary or even a good thing so you have the option of suppressing some or all of it. A subject doing a particularly difficult experiment and having the word "WRONG" flashing up a lot might become upset/discouraged and stop responding according to the instructions given or just switch off. I personally feel that unless there is obvious benefit for having feedback, then it is better switch it off. Perhaps you may want to have feedback in the practice block but not in the main part of the experiment. It's up to you. You can change the feedback to fit your design and I have an example of what you can do with feedback.

There are a few common errors that people make. If your file won't run or crashes you should check it for the following Missing clock on symbols, missing frame delimiters, missing +/- signs before your item numbers. If an item requires a response of any kind (i.e. it begins with a +, -, ^ or = then there must be a clock on symbol * in the item. Conversely if the item does not require a response then there must not be a clock on symbol. If you get a 'file not found' error message for a sound file or graphics file, the first thing to do is to check that the spelling used in your RTF file is the same as the spelling of the sound/graphics file. There is also section in the DMDX help pages about error messages - you should read it. Return to Tutorial Return to Tutorial Page created and maintained by Mike Ford -- Main.CarolineWhiting - 17 Sep 2007