<Delay [option] N>
<d [option] N>
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
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 scheduled as quickly as possible plus the absolute value of the parameter --
no error will be thrown if the time cannot be met. 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
times). NOTE: these optional negative or zero values only apply to the
parameter version of D, the switch version used in a frame is interpreted
Delay is usually used in conjunction with the
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
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
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
and as noted above is interpreted literally, it cannot be zero or negative
(unless you want unpredictable behavior 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 (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
<MultiScrambleDollars> we deemed it
was ok to appropriate it for <msDelay>...