DMDX Help.


Delay Keyword

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

variants:
Millisecond Delay Keyword

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

option:
period



    D parameter and switch alternative.  There is now a discussion of <delay> and it's intricacies in the Introduction.

    The Delay value specifies the exact time in ticks between a request and first display of the next item (if not specified the default is 48 tics or about 800 ms on most machines).  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 be specified in milliseconds and it will be rounded to the nearest tick unless the freesync modifier to the video mode is being used in which case the millisecond time will be used as is.

    The Delay parameter can be negative (unless you're using the period option) in which case the display is laxly scheduled as quickly as possible plus the absolute value of the parameter -- no error will be thrown if the time cannot be met (hence laxly).  The D parameter 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).  NOTE: these optional negative or zero values only apply to the parameter version of D or <delay>, the switch version used in a frame is interpreted literally.

    Delay is usually used in conjunction with the <ContinuousRun> keyword where the request time is the time the last item's last frame is presented (and not the time that a response was received, a trap that rather a lot of people fall for when they just want a longer delay between items and they wind up getting display errors in almost every item except those with short RTs because their display is not longer than their RT timeout -- they should really be using a lax negative delay parameter instead of the default rigidly controlled one).  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 would determine the item's duration and thus you wouldn't get a fixed ISI (and of course doing so meant one could not have feedback without exceptional levels of scriptfu).  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. When 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 unintended 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 and as noted above is interpreted literally, it cannot be zero or negative (unless you want behavior that is difficult to predict anyway).  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.  While you could schedule an out of order display the display generating code assumes frames are in a timewise order when considering what needs to be erased on the screen so all sorts of display artifacts are in play as well.

    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 they 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> in version 4.2.0.0.



DMDX Index.