|
Useful DMDX Links:
DMDX related Tools
and Tricks
Other Free
Presentation Programs:
Getting
Started
From the Official
DMDX page, download and unzip the most recent version of DMDX. You may find
it useful to make shortcuts to DMDX and TimeDX, since they don't install
themselves in the start menu. If DMDX complains about not finding a
registry key associated with video settings, run the TimeDX "Time
Video Mode" and choose "Save Last Value in Registry". You
may need to run several TimeDX tests before DMDX will work properly. DMDX
comes with help files, the "Keyword" help to be particularly
useful.
Write your DMDX
programs in Word or Wordpad. All programs should be saved as rtf (rich text
format) files. If you have trouble with programs saved in Word, reopen them
in Wordpad and save them. Programs consist of two parts: 1) the extended
parameters on the first line that tell DMDX general characteristics of the
program, and 2) the items to be presented. Here is a very simple program:
F500
<cr>
1 "Hello World"/;
Here are what the
parts of the program mean:
Parameters:
Frame length=500 ticks,
continuous run,
Items:
item "1",
display "Hello World", (by default, black letters on a
white background)
"/" ends the frame (after 500 ticks),
";" ends the item
The
MR3 Scanner Mice
One of the things
you'll need to know to save mouse press information for subjects at the
scanner is that particular codes correspond to particular mouse buttons on
the two mice at the scanner, like so (this is how it works for DMDX
anyhow):
Start
the Scanner with DMDX in 3 Easy Steps
As we undergo
hardware and software changes at the scanner, ...and as people experiment,
we learn more. Special thanks goes to Shioahui Chan who spent a lot of time
and effort figuring out what happens and why). 1) Add 2 Lines (shown in red, below) of code to your DMDX
program. These should, of course precede any items that will be part of the
experiment.
<ep> F118
d5<ContinuousRun> <RecordClockOnTime> <nfb>
<AzkiiResponses> <dfs 80> <bgc 000000000>
<writingcolor 000255000> <zillion> <id
"keyboard"> <id pio12> <eop>
0
"READY?" ;
100
<Output 254> c;
101 <o 255> %1 / <o 254>/ "READY?" <ms% 4000>/;
1001 * + "XXX";
The parameter line
(in black at the top) has several standard DMDX specifications. The only
critical parameter is probably that you use continuous run "
<ContinuousRun> or <cr> ".
The first item line (in black) (0 "READY?" ;) is used to just
have something on the screen when you first press RUN on DMDX. The screen
will be displayed until you can press the space bar to start the
experiment.
Lines 100 & 101
trigger the start of the scanner, followed immediately by another
"READY?" screen which will stay on for the specified number of
milliseconds (ms% = set milliseconds for this frame duration), in this case
4 seconds (2 TRs). Test the timing to make sure you have a blank or
"Ready" (as in this example) set to stay on for the correct
number of TRs.
Experimenters should
not begin to collect data during at least the first 5 TRs. The scanner
starts at item 100.
The scanner is
triggered by the <Output 254> statement (also written <o 254>).
It turns out not to be necessary to have the "254" statement in
there twice (at least, not for the 3T as of February 2006). It may be
necessary with different hardware, so always try before you commit. It
apparently doesn't hurt anything to have it in there twice...but the second
command is ignored.
The "c" in
item 100 means "continuous run". It seems not to be necessary as
long as "continuous run" was already specified in the parameter
line at the head of the file (so, we really don't need it in our example,
because we have <ContinuousRun> in our parameter line).
<o 255> sends
an "inactive" signal to attached hardware. <0 255> will not
start the scanner. In fact, <o 255> appears to be unnecessary.
In item 101, the
order of the parameters <o 255> and <o 254> did not appear to
matter. The scanner always started with <o 254>.
In sum, if you keep
both lines, you should understand that the scanner is triggered at line
100, NOT 101.
You could trigger the
3T scanner (at least) with either of the following single line commands,
instead of the red 2 line command above:
+100 * <t 0> <Output
254> c;
or
+101 <o 255> %1 /
*<o 254>%1/ "READY?" <fd 724>/;
or, probably even:
+101 *<o 254>%1/
"READY?" <fd 724>/;
If you use line 100, the time
out parameter <t 0> makes the item disappear as quickly as possible.
So, use this line to trigger the scanner immediately with no delay (or as
close as you can get to no delay).
If you use line 101, note that
it has been altered from our original command to wait for 12 seconds <fd
724> (frame duration 724 in ticks-which corresponds to about 12 seconds
on Pharaoh) instead of 4 seconds. We have added the * so that DMDX COT will
be synchronized with the scanner. %1 is a frame duration of one tick (if
left unspecified, frame duration will correspond to your default (which may
be pretty long).
The last line is a
sample stimulus. The rest of the experiment would follow as usual.
2) The black BNC
cable (marked "TO MRI TTL", and coiled on the floor near the
patch panel, on the side opposite the computers) from the MRI computer gets
plugged into the
button box BNC port labelled "To MRI TTL".
3) On the User CVs
page on the MRI console, set "External Trigger" to "1"
(default is "0").
This tells the scanner to wait for you to press the "Scan" button
before it begins the experiment (actually, it gives you 24 seconds in which
to press the "Scan" button.
Writing
your DMDX programs in Excel
Some users have found
it very helpful to write their DMDX programs in Excel, save the
excel file as Formatted Text (space delimited), and then open it in
Wordpad, do minor editing to eliminate extra spaces, and save it as .rtf
file. The key is to create item numbers so that you can sort by condition
and then utilize all the useful excel copy and sorting commands to make
your programming life easier. Also, it is important to have your columns
wide enough to display all the text in each cell, otherwise whatever is not
viewable will be lost iin the conversion to wordpad. To see such an Excel
file, go
here and
download sample.xls.
Zilverter
Zil files with
multiple responses are pretty complex and do not import into excel easily.
To circumvent this problem we have created zilverter, a java program that
will mark up a zil file (as long as you have not altered it) as xml so that
you can then extract the information of interest into columns. The
zilverter.zip
file includes a README.txt that explains how to install and use the
program, an xsl file that extracts the data into a csv file suitable for
excel, a test zil file (so you can make sure zilverter runs on your system
and see what file format it expects). It also includes several jar files
which you should just leave there...they are important to the process of creating
xml, but you don't have to do anything to them or put them anywhere
special. Just leave them in the directory with your other zilverter stuff.
Before you unzip
zilverter.zip, you should put it in a directory of its own.
Before you try to run
zilverter, read the readme and install the (java runtime environment)
jre 1.4.1 or later. Make sure the jre you
installed is at the beginning of your path (again, see the redme for
details).
You should find that
you can get the whole thing installed and running in under an
hour...especially if you are running on Windows 2000 or XP (which the
readme assumes).
Matt Davis's awk
tools
First off, you'll
want to go to Matt Davis's homepage and get the tools:
Matt Davis's
Homepage (and useful scripts)
You'll find two
tools: gawk.exe is the Awk text-processing programming language for
Windows. Put the executable in a reasonable place (Davis suggests creating a directory
"bin" on your c drive and putting it in there. In addition, Davis provides a
script written in the awk language and intended to reformat the DMDX azk
output. The script is called getdat.awk. Put it in the directory with
gawk.exe. Davis
provides an example of how his awk script reformats the data on his page.
He also provides instructions on how to run the script by right clicking
your azk file and choosing "convert to text"...after you set up
the right click option and add or change some file associations.
getdat is a nice
script for formatting .azk files. However, it does not extract COTs. It is
designed to format .azk files w/ multiple subjects by Subject # and then by
Item # and RT. Note: COTs are not output ! If you want COTs output, run
getdat_with_rcot.
We found the
following just as easy (easier?) as we had some trouble setting up the
right click options under Windows XP.
Extract Zip file to
desktop.
Create folder for
getdat, getdat_with_rcot & gawk (I created a folder called 'bin' on the
C drive: C:/bin).
Move gawk and getdat
into C:/bin.
Move your .azk file
to C:/bin
To launch command
prompt: Start Menu->All programs->accessories->command prompt
In command prompt
window move to your directory where your .azk files and getdat & gawk
are located.
>C: <enter>
>cd bin
>dir (command for examining contents of the folder/directory-your
files should be listed)
>gawk.exe -f getdat.awk "test.azk"
This produces test.txt in the same directory with only the RT
data for each subject. This should be a nicely formatted file that can be
opened using Excel.
or
>gawk.exe -f getdat_with_rcot.awk "test.azk"
This produces test.txt in the same directory with the RT AND COT
data for each subject. This should be a nicely formatted file that can be
opened using Excel.
|
