DMDX Help.


Eye Tracker notes.


    As of version 6.1.0.0 DMDX can interface to an eye tracker such as those made by Gazepoint controlled over a TCP/IP connection although it is by no means limited to those, any device that has a TCP/IP API like the Open Gaze API can be interfaced with not to mention the possibility of custom written software to control DMDX as bidirectional communication is easy to set up (for instance sham conspirators are no longer absolutely necessary and instead you could have real networked conspirators running DMDX on other machines). 

    To interface with an eye tracker the tcpip input device must be invoked (with <id tcpip> for instance), after that 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.  If multiple lines of data are received before the next item commences only the last line will be available in  the .tcpipreply. macro (the skipped preceding ones are still written to the output file however).  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. 

    Should writing item files that manipulate macros not be your cup of tea or more specifically if you need DMDX to react within a single tick (as most macro based solutions are going to be generating new displays in two tics at best) as of version 6.1.2.0 of DMDX the 2Did tcpipreply device can be used to map arbitrary areas of the screen that the subject's point of gaze falls on to signals to either generate RTs or more usefully that DMDX can use to trigger display changes with the <expireif> keyword.

    While straight forward passive use of tcpip is the obvious use of the device 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 debug modifications to 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 "t\'00h\'00e\'00" 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.

    If you're running both DMDX and the eye tracker on the same machine and they present too much of a burden on the machine (loading it's CPU up to 100% all the time) then you could invoke relaxed raster tracking and DMDX will consume significantly fewer CPU resources.
 

   



DMDX Index.