|
- Some of the points may only be suitable for University of Arizona locally.
- Use MS WordPad to edit the DMDX .rtf files (if you’re using Windows)!
- NotePad should be okay, too, but WordPad can also set the format of fonts (size, fonts, colors…) directly.
- Definitely don’t use MS Word to edit. It’ll add in some formatting codes (you can see them if you open a file edited and saved by Word in NotePad).
- Sometimes if you encounter unknown problems when you try to run a DMDX script, one of the troubleshooting steps is to open the .rtf file in WordPad, correct errors if needed, and then save it to another file. Or you can even just open it in Word, but paste and copy onto a new file in NotePad and save as a new rtf file.
A simple DMDX (.rtf) example file for fMRI experiments:
<VideoMode 800,600,600,16,60> <RecordClockOnTime> <ContinuousRun> <id pio12> <MapPositiveResponse +bit1> <MapNegativeResponse +bit2>
100 <Output 254> c;
+101 <o 255> %1 / * <o 254> %1 / "Ready?" <% 970>/;
+1 * "LEFT" <% 30> / ;
-2 * "RIGHT" <% 30> / ;
Some Notes:
· If you are using our Resonance Technology Inc. video goggles to display, you should set your video mode (in DMDX script) at 800x600 and 60 Hz or lower. This is the factory setting for those goggles. If you set it to higher resolution, it will still run, but we are not sure what’s the real display parameters on the goggles then.
· <RecordClockOnTime> can give you accumulative timing information wherever you have a ‘*’. You will want these to get the trial onset information for data analysis (e.g., SPM).
· Usually you’ll want to use <CR> (ie. <ContinuousRun>, DMDX recognizes many abbreviations).
· If you use the mice in the scanner, you need to specific <id pioi12>. This is the port on our customized device card on Pharaoh (the presentation desktop computer at MR3). It’s different from using the mouse in front of Pharaoh.
· <id pioi12> should be specified before any button mapping (<MPR> <MNR> etc.).
· Mice’s button mapping (L: left; M: middle; R: right button):
Left mouse (see the label on the mouse)
L M R
1 4 2
Right mouse
L M R
5 7 6
· More details on button mapping see:
http://cnl.arizona.edu/dmdx.htm#mice
· Usually you can just copy the 100 and 101 lines to your script to trigger the scanner (after the DMDX header and before the other trail lines). <o 254> is where the scanner actually starts (signal send to the scanner via TTL pulse), so we put the first ‘*’ there, to record the actually beginning time of the scanner. But note that the scanner will run the dummy scans first (if you specify them), then the real scans.
· In this example, Pharaoh will try to trigger the scanner once this DMDX script is run, because there’s no stopping point before line 100 and 101. So you need to hit the “SCAN” button at the console before this running DMDX script.
· Using <VideoMode 800,600,600,16,60>, Pharaoh’s refresh rate should be 16.57 ms (depends on the machine and settings). This is also the “tick” duration for your DMDX script. You can also find it in your DMDX result (.azk) file (at the beginning).
· For this example script, “Ready?” will be on the screen for ~16072.9 ms (because of <% 970>) while the scanner is running the dummy scans. This duration is better to set to be equal to or longer than the dummy scan scanning time (number of dummy scans * TR; e.g., 8*2sec=16000ms) to ensure that when the first real DMDX trial is running, the scanner has already started the real scans.
A more complicated example:
<ep>
<vm 800,600,600,16,60> <rcot> <cr>
<id pio12> <id "Keyboard"> <id "Mouse"> <UnMapButton> <mpr +bit1> <mnr +bit2> <mpr "+Button 0"> <mnr "+Button 1"> <mr +Space>
<fd 30> <t 500> <d 20>
<dbc 255255255> <dwc 0> <nfb>
</ep>
0 “Ready?” / !;
100 <o 254> c;
+101 <o 255> %1 / * <o 254> %1 / “Wait for the first trial…” <% 970> / ;
+1 "+" <% 30> / "face" <% 30> / "#########" <% 37> / ;
-2 "+" <% 30> / "house" <% 30> / "#########" <% 37> / ;
+1 "+" <% 30> / "face" <% 30> / "#########" <% 37> / ;
0 “End” <% 1207> / !;
Some Notes:
· <id pio12> and other <id>’s should go before <UnMapButton>, and <umb> should go before <mpr>, <mnr> etc..
· If you are using two mice in the scanner, you might need to use <MIP 366> in your header.
· It’s a good idea to also <id> (<InputDevice>) Keyboard or Mouse, because then you can still control the experiment at the console or do testing.
· If you’re displaying big file stimuli (e.g., images), you might need to increase <delay> to avoid too many delay errors.
· In this example, you will start and run the DMDX script. “Ready?” will be on the screen first. Then you can hit the “SCAN” button at the console to allow the scanner to start to wait for the trigger signal (within ~25 secs). When you hit Pharaoh’s spacebar, DMDX will move to the next lines (100 & 101) to start the scans. You should hear the scanning noise immediately.
· You can also put some practice trials at the beginning (and throw out later) instead of letting the participant just wait.
· It’s a good idea to leave some time at the end (e.g., 20 sec) to let HDR going back to baseline.
· Don’t try to change the video settings of Pharaoh directly if you don’t know what you are doing.
· Be sure to do a test run of the entire script before you go to the scanner. Make sure it won’t crash in the middle, check the total duration, errors and response recording in .azk files etc.. Also do a whole dry run test at the scanner before you put in a real participant. See if the script can trigger the scanner and if the button pressings are recorded correctly (+ or – signs, timings).
· The total time measured from the test runs can help to determine the total repetitions of TRs (frames) that you need. If your experiment will have various durations (e.g., self-paced), you need to estimate the repetitions you need. It can also be modified for each participant or sessions (scans).
· It’s a good idea to make a very short version of your script to test before your scan every time. Sometimes the recording may have problems, and you don’t want to find out it after you finish the experiment.
· It’s a good idea to use Excel to edit the first draft for the .rtf script. Excel is good at formatting the trials and ordering/randomizing them. It’s also good to use Excel to load in .azk results to sort them by conditions (item codes) and do calculations.
· You can change fonts (color, size…) of your stimuli in the rtf file directly (and it will appear when it runs), or specific it using parameters in the header (for all trials) or for each trial separately (e.g., <DefaultFont Arial>).
· If you want to use parameters to use some special fonts, you may still need to have at least some words in the .rtf file that’s set to use that font.
Prepare “vector of onsets” for SPM analysis:
- First you need to sort the trials in the azk files by condition. Then you need to calculate the real onset time of the trial (relative to the first real scan) for SPM. In short, if you use the settings similar to the ones described in this document above, the real onsets will be the COTs in the azk file minus the dummy scan duration (number of dummy scans * TR). Remember you need to convert this value to secs or scans for SPM. See the figure below for an example:
|
