DMDX Help.


Timing Notes.

Continuous Running considerations.

    An increasing number of people are using DMDX to control display sequences where physiological data is gathered by another machine, be it an FMRI machine or a BIOPAC.   These sequences are usually using continuous running and must have a rigidly fixed ISI using the delay parameter, which tend to put them beyond the considerations prevalent when these were coded making the overall desired result somewhat awkward (as if regular DMDX wasn't awkward enough anyway).   There are many considerations here, hopefully I can shed some light upon the most common of them.

    The first consideration is to do with the duration of a frame.   When you specify a frame duration you are not actually specifying a frame duration, you are specifying the time at which to schedule the next frame for display.   Sounds straight forward and tautological even, however if there is no next frame in an item DMDX simply displays that frame and moves on to the next item, regardless of any frame duration specification.   Assuming we want a 40 tick presentation (a tick being the time from one vertical retrace of the monitor to the next) for three items the obvious solution to the above problem of a rigidly controlled fixed length display sequence is not the following:

d10 f30 <cr>
0 "start";
1 "first";
2 "second";
3 "third";
0 "stopped" l;

    The actual duration of the sequence from "start" to "stopped" is 33 ticks, 10 ticks per item for the delay parameter and 1 tick to display the word.   Once the word is displayed DMDX moves on to the next item, the request time (from which the delay is taken from) is the first time DMDX examines the display queue finding no more elements needing processing (because of the continuous running), so the f30 is meaningless in this example.
    The solution then is to give DMDX another frame:

d10 f29 <cr>
0 "start";
1 "first"/!;
2 "second"/!;
3 "third"/!;
0 "stopped" l;

    Here the duration is now our desired 120 ticks, 10 ticks per item for the delay, 29 ticks per item for the words and 1 tick per item for the frame that doesn't erase what's already on the screen.

    The next hurdle people encounter is displaying bitmaps, here the image can take a large portion of a second to load so determining a value for the delay can be problematic.   The solution is a simple extension of the first item file but to deliberately have the delay determine almost the entire duration of the display.   Assuming we want a 3 second ISI and the refresh rate is 60Hz the following is required for a 9 second sequence:

d179 f30 <cr>
0 "start";
1 g "first";
2 g "second";
3 g "third";
0 "stopped" l;

    The f30 is superfluous, it isn't used but it's always a good idea to specify.   Here each image is loaded as the previous is displayed allowing ample time to read the image files from disk.

    Should individual frame require presentation for longer (or shorter) periods the delay can be overridden in individual frames, here we want second.bmp to be displayed for 6 seconds for a total sequence length of 12 seconds:

d179 f30 <cr>
0 "start";
1 g "first";
2 g "second";
3 d359 g "third";
0 "stopped" l;

    Gathering RTs is more complicated.   You have to ensure that the display determines the duration of the item, you must set the timeout lower than the item display duration.   While theoretically you could leave the feedback enabled as it should have a constant display interval I don't think it's ever been put to the acid test and who knows what you'd have to do with the delay value:
   
d10 f29 <cr> t490 <nfb>
0 "start";
1 * "first"/!;
2 * "second"/!;
3 * "third"/!;
0 "stopped" l;

    Here f29 actually does something.   It will be gathering responses for a tad less than half a second followed by 11 ticks of time to assemble the next item during which the display will not have changed.

    Lastly, gathering RTs and displaying bitmaps requires sectioning each item into two distinct portions, an active part where an RT is gathered and a passive part that is loading the next bitmap:
   
d59 f120 <cr> t1990 <nfb>
0 "start";
1 * g "first"/!;
2 * g "second"/!;
3 * g "third"/!;
0 "stopped" l;

    Here we still have a three second per item display, the first two seconds of which can have a response made and the last second is buffering time to load the next bitmap while the display still shows the previous bitmap.




DMDX Index.