chain keyword, you can however unmap all the
devices' buttons with <UnMapButtons>.
Names with special characters in them must be quoted and the
Unicode option turned on.
One problem prior to version 6.1.2.20 of DMDX used to be devices having cute little symbols
(such as the copyright symbol) as
part of the name making it very hard to get the name of a device into an item
file, these days with many people using Asian characters you can get whole names
without a single Roman character in them that are all but unusable unless they
happen to be a keyboard or a mouse where #keyboard or #mouse can be used. As of version 6.1.2.20 DMDX uses the wide versions of the
DirectInput system calls so it has access to the Unicode versions of the names
of devices and buttons (rather than the mangled versions once the cute
characters are converted to whatever the current code page of your machine is)
so as long as you've got the Unicode option
checked and enclose the names of your devices and buttons in quotes you should
be able use them, and as of 6.4.0.0 even the quotes shouldn't be needed (unless
your device name has spaces in it) as
Unicode text outside quotes is now preserved as UTF-8 (which will get converted
to UTF-16 wide characters when talking to DirectInput). Of course the problem then becomes knowing what those
names are as until I modify TimeDX's input test
to use Unicode names they'll be mangled there. To combat this DMDX dumps the names of available
input devices into the diagnostics where
you should be to view the UTF-8 versions of the names (once again, as long as
the Unicode checkbox is checked) and
copy and paste them into your item file. Should that fail it also checks a parsed
version of the name that has unusual characters removed from it that is also
printed in brackets -- which is fine unless all the characters of your
device or button name happen to be special characters as happens with Asian
character sets for example which is why the 6.1.2.20 modifications were made...
Additionally
<Testmode 10>
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
parameter N2
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).
It's default polling period is 100ms.
- 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.
Parameter N1
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
Abort key. Note that the
overrun protection should never be longer than the timeout period if you're
using the DigitalVOX device as well as the RecordVocal device unless you
specify a lower polling period in the DigitalVOX spec as the DigitalVox code uses the overrun protection value as it's wake up period to
examine newly acquired voice data and if that period is longer than the
timeout it will never examine any data (so
<t 500> <id recordvocal 150,1500> <id digitalvox 100> for example).
- 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 6.1.0.0 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.
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
to the
.tcpipreply.
macro after any CR or LF characters have been removed.
See the eye tracker notes for usage
details.
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 5.2.1.0 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).
DMDX Index.