Input Device Keyword
<InputDevice text [N1[,N2[,N3]]]>
<id text [N1[,N2[,N3]]]>
<id tcpip [address[:port]]>
Parameter to select an input device. text must be the name of an existing installed DirectInput device (as enumerated by the TimeDX input test) or the name of one of the internal devices built into DMDX (see Input), such as
"PIO12" (the built in MetraByte PIO12 (or clone) interface), "DigitalVOX",
"RecordVocal" (see Audio Input)
or "tcpip". Once a device is selected there is no way to deselect it without starting a new item file which can be done with the
chain keyword, you can however unmap all the
devices' buttons with <UnMapButtons>.
Names with spaces in them must be in quotes.
One problem is devices having cute little symbols as
part of the name making it very hard to get the name of a device into an item
file. To combat this version 22.214.171.124 of DMDX dumps the names of available
input devices into the diagnostics, not only that it also checks a parsed
version of the name that has unusual characters removed from it that is also
printed in brackets.
can also be used to combat weird naming problems.
- If the name of the device is a DirectInput
device and includes a space as a number of devices do then text can be delimited with double quotes, "text name". If the device is a polled device (see Input) N1 specifies the number of milliseconds between polls when DMDX is
idling between jobs (usually waiting for a request), the default interval being 10ms. The second
specifies the time between polls when the clock is on (when a response is to be gathered), the default being 1ms for the PIO12 and 3ms for all other polled input devices.
- If the device is the DigitalVOX only one
parameter, N1, is applicable and that sets the Digital VOX's period (see Audio Input).
- The redesigned RecordVocal device
introduced in version 3.0.0.09 can now use two parameters. When used
without any parameters it runs in legacy mode where it records vocalizations
for the entire timeout period.
if used changes the length of data recorded to be N1
milliseconds longer than the trigger provided by the DigitalVox device.
Currently DMDX only records extra data for approximately the period specified.
The last parameter N2
determines how much overrun protection DMDX allows and is by default 50ms. I
didn't expect anyone would ever have to use this but it would appear that a
number of machines need 500ms of overrun protection so if your recordings are
getting chopped up then try a value of 500 for N2
(see the RecordVocal Notes). If you want RecordVocal to
run in legacy mode but need to lengthen the overrun protection specify N1
as zero. The new RecordVocal code can also be aborted with the
- In the case of the queued input devices (QPIO12
and so forth) the third parameter N3 increases the size of the queue used to buffer data. The default buffer is 16 entries long allowing for 16ms of buffering, some machines may require more buffering indicated by repeated PIO Polling FIFO full at time %dms error messages.
- Input device names mouse, keyboard and joystick can be prepended with a
#. Typically with
non-english input devices its best to use the
# versions of them instead of their named versions.
When a device is mapped this way button names are no longer used, button
numbers are used instead. Then you can use things like
<mr +#0> -- but be careful if you use
more than one
input device as you'll have two #0
buttons and won't be able to map buttons on the second device...
- The tcpip device is a built in
device added in version 126.96.36.199 of DMDX that opens a TCP/IP socket to a specified machine (or the local
machine with using the loopback address 127.0.0.1 if no other address is
specified) on the port specified (or 4242
if not specified) to control an eye tracker or other piece of equipment.
The machine's address can either be an IPV4 dotted quad, an IPV6 address
with colon separated hexadecimal quadruplets or a DNS name. When the
tcpip device is in
use the <send>
keyword sends strings of characters
to the selected machine and any received data is written to the output data file as well as assigned
macro after any CR or LF characters have been removed. In addition as
of version 188.8.131.52 of DMDX the
tcpipreply device can be used to map arbitrary areas of the screen that
the subject's point of gaze fall on to
signals to generate RTs. If multiple lines of data are received before
the next item commences only the last line will be available in the
.tcpipreply. macro. Note that you won't want to manipulate
.tcpipreply. directly if you have a stream of data constantly coming
in as it will be redefined all the time, instead you'll want to take a copy
of it before parsing that copy instead of
.tcpipreply..as our example
in the <send> keyword help does.
In addition to just synchronizing the data you could
actually completely control the eye tracker as you can send any command (like the ones to get the gaze
point or initiate a calibration session) and filter the reply with DMDX's macro stack operations. Not only that, the tcpip device opens the door for people to
write companion programs to DMDX to control it's operation by listening for
a socket connection from DMDX and then responding and issuing commands to a
script that DMDX runs (which is basically all I was doing testing this with
the Monitor application, I just wasn't doing anything fancy with the replies).
For instance because you can use a macro for the entire body of an item
there's nothing stopping you from writing a general purpose DMDX script that
simply takes a tcpip reply (or a section of one) and using that as the next
item ad infinitum (special characters aren't filtered so double quoted text
segments are A-OK -- although you would have to match up the RTF font table
with any \f RTF control words and if you're using the Unicode option you'd
have to mark your text up to be wide characters with
for "the" for instance -- and you could even put a semi-colon in there but you'll
like as not break something so don't do that). Only thing you can't do
is have the item file scrambled but that's kind of antithetical to the whole
approach of having another program control DMDX anyway.
Certain devices come with preinstalled
button mappings, see Input and <MapRequest> etc.
Certain operating systems preclude the use of certain input devices. Most notably Windows NT (not that anyone would want to use DMDX under it), Windows 2000 and Windows XP
and later (Vista, Windows 7, 8 and 10) preclude the use of devices that involve direct access to I/O ports. While InstaCal drivers can be installed and used for the PIO12 devices no such thing
was available for the RawJoystick device until version 184.108.40.206 of DMDX where
support for inpout32.dll was added (see the PIO
test documentation for details, to use it you will first need to run
InstallDriver.exe in the DMDX program folder with administrative access to
install the ring 0 kernal mode driver interface for the DLL).