DMDX Help.


Delay Keyword

<Delay [option] N>
<d [option] N>

variants:
Millisecond Delay Keyword

<msDelay [option] N>
<msd [option] N>

    D parameter and switch alternative.

    The Delay value specifies the exact time in tics between a request and first display of the next item.  The only option so far is the period option (which is only available as a parameter) that specifies the exact period of items (from the start of the display of an item to the start of the display of the next), in effect an ISI.   In very early versions of Dmastr the <RequestScheduled> bit of the Method Of Display had to be set as well, however for a number of years both the Delay parameter and the Request Scheduled bit have operated in parallel.  The millisecond variants allow the delay to specified in milliseconds (will be rounded to the nearest tick).

    The Delay parameter can be negative (unless you're using the period option) in which case the display is scheduled as quickly as possible plus the absolute value of the parameter -- no error will be thrown if the time cannot be met.  D can also be zero which simply means get the display up as quickly as possible, the delay being determined by how long it takes DMDX to prepare the item (see Preparation times).

    Delay is usually used in conjunction with the <ContinuousRun> keyword.  Prior to the introduction of the period option whenever you designed an item file that was to have a constant ISI and you wanted subject responses you had to arrange things such that the duration of the frames displayed was longer than the longest response, otherwise the subjects RT will determine the item's duration.  Today however such concerns are moot and any requirement for a constant ISI should now use the period option.  See Continuous Running considerations in the timing notes. Using the period option the display's duration is no longer required to be longer than any response, instead the delay period itself it will have be longer than both the display and any possible response greatly simplifying rigid ISI item files.  You can even have feedback as long as you allow for it's half second or so display in the duration of the period.

    Delay used in an item (as opposed to on the parameter line, it's normal usage) must be in the first frame of an item otherwise it's use is likely to produce complex and wrong behavior.   When used in the first frame it overrides the default delay specified in the parameter line and specifies the delay for just that item (not the next one), it does not affect the delay specified in the parameter line and does not affect any other item.  Technically what it does is allow you to specify the delay from the request (or the previous item's first frame if you're using the period option) for every frame regardless of the previous frame's duration (so you could schedule an out of order display but good luck figuring out what's happening when it runs).

    One thing to note about the period option here that is perhaps not obvious when one is used to the way <Delay> normally works and that is that sticking an instruction in the item file will cause the next item to throw a display error unless the subject dismisses the instruction before the period expires.  Normally the delay is timed from the request of the previous item so no matter how long the user takes to request the end of the instruction the delay isn't a factor.  However when using period the timer is always running from the start of previous item's display, long before the subject requests the end of the instruction and thus causing the first frame of the next item to have a display error (unless they happened to be fast enough to beat the period of course).  So there's code in there that suppresses display errors after instructions when period is being used by rescheduling the following frames if the need to be.
   
    If you have a <Delay> parameter you might want to use the TimeDX / Advanced / Task Priorities / Always Flush File Buffers option so that you have a constant amount of activity at the end of any given item, otherwise some items will have disk activity as Windows decides that a given file's buffer is now full and it needs to be written to disk and other items will not.  Disk subsystems tend to be fast enough and processors parallel enough these days that this is generally a hindrance and slows everything down so don't use it unless you need to.
   
    Note that the terse keyword <msd> was previously used for multi-scrambling, but given that there were two terse versions of <MultiScrambleDollars> we deemed it was ok to appropriate it for <msDelay>...



DMDX Index.