Skip to content

Developing EyeScript

Felix Engelmann edited this page Feb 7, 2014 · 2 revisions

Documentation of classes

experiment.py

The experiment.py module contains the Experiment class that is responsible for taking care of the global settings in an experiment (e.g. display settings, initializing the eyetracker, etc.). Every EyeScript script must create an Experiment object before running the session. This module also has some other classes that take care of data logging, creating eye-tracker stub, etc.

The classes are:

The utility methods (Utility methods: Experiment) are:

  • def checkForResponse()
  • def updateEvents()
  • def getEvents()
  • def getDevice(device_class)
  • def setUpDevice(device_class)
  • def getExperiment()
  • def getTracker()
  • def getLog()
  • def calibrateTracker(colors=None)
  • def runSession(callback)
  • def formatMoney(amount)

trials.py

The trial.py module defines the abstract Trial class from which all trial definitions inherit. It also defines functions that may be called within a trial for eyetracker communication.

It contains the following classes:

  • :ref:`class-trial`
  • :ref:`class-pupilcalibrationtrial`
  • :ref:`class-eyetrackererror`

The utility methods (:ref:`trials-utility`) are:

  • def startRecording()
  • def stopRecording()
  • def driftCorrect(color=None, ... )
  • def gcFixation(target=None, ... )
  • def gcFlashFixation(target=None, ... )

display.py

displays.py defines the top-level Display class, along with child classes for specific types of stimuli. These classes are responsible for presenting stimuli and instructions on the screen during a trial.

It contains the following classes:

  • :ref:`class-display`
  • :ref:`class-textdisplay`
  • :ref:`class-audiopresentation`
  • :ref:`class-imagedisplay`
  • :ref:`class-slidedisplay`
  • :ref:`class-continuedisplay`
  • :ref:`class-interestarealabelerror`
  • :ref:`class-wordtoolargeerror`

The utility methods (:ref:`display-utility`) are:

  • def fullViewport(stimuli)

response_collectors.py

response_collectors.py defines the abstract ResponseCollector class and modality-specific response collector classes inheriting from ResponseCollector. It contains classes for accepting and logging input via various modalities.

For scripts response collection always coincides with the display of a stimulus (the usual case), the script would generally not need to directly create or interact with response collectors. Display objects automatically create response collector objects to collect responses to the stimulus displayed (:ref:`class-display`), unless the response_collectors parameter of the Display object is explicitly set. The type of ResponseCollector object automatically created is set by the response_device parameter. For instance, TextDisplay("Button 1 or 2?", response_device = ButtonBox, possible_resp = [1,2], cresp = 1) would result in a ButtonBox object (inheriting from ResponseCollector) being created, whose possible_resp and cresp parameters would be set to [1,2] and 1 respectively. This ButtonBox object would start collecting responses at the onset of the TextDisplay, and the TextDisplay's run() method would return when the ButtonBox object returned a response.

Response collector objects would need to be created directly in the script if, for instance: ~ (1) More than one response needs to be collected after a stimulus display (e.g. in a dual-task experiment). (2) Response collection needs to continue after the stimulus is done displaying

Some parameters of the ResponseCollector can only be set after the associated Display object is created (in particular, if the possible_resp and/or cresp parameters of a ContinuousGaze response collector object are interest areas calculated when the associated Display object is created)

You can access the data of a response collector object using the notation of Python dictionaries. For instance, if rc is a type of ResponseCollector, say a Keyboard object, then ~ - rc['rt'] is the response time (in milliseconds) for the keyboard response - rc['resp'] is the subject's response (the key pressed) - rc['cresp'] is the correct response if this was specified - rc['acc'] is the accuracy (0 or 1) of the subject's keyboard response (if cresp was specified) - rc['onset_time'] is the timestamp of the instant the response collector started accepting responses (corresponding to the timestamps in the EyeLink edf data files) - rc['rt_time'] is the timestamp of the instant the response was made (corresponding to the timestamps in the Eyelink edf data files)

You can also access any of the response collector's parameters through dictionary notation (e.g. rc['possible_resp'])

It contains the following classes:

  • :ref:`class-responsecollector`
  • :ref:`class-eyelinkbuttons`
  • :ref:`class-keyboard`
  • :ref:`class-mousewidgetclick`
  • :ref:`class-mousedownup`
  • :ref:`class-gazeresponsecollector`
  • :ref:`class-gazesample`
  • :ref:`class-continuousgaze`
  • :ref:`class-cedrusbuttons`
  • :ref:`class-speech`

The utility methods (:ref:`responsecollector-utility`) are:

  • def byteToKey(bytes)
  • def bytesToRT(bytes)

lists.py

TBD

devices.py

TBD

shapes.py

TBD

interest_area.py

TBD

default.py

TBD

Clone this wiki locally