This page is for describing design issues and corner cases as well as explaining some design decisions.

Here are the components (classes, modules) that can be worked on and tested somewhat independently.

Specific class which implements the graphical interface of an experiment. In the Qt implementation (e.g. QtBackend), it is a QMainWindow with each experimental task represented as a tab. Provides a nice interface for the Experiment class to use as it's graphical representation. Also provides a mechanism for switching from task to task and starting/pausing tasks.

Status: Qt backend has been worked on a bit. Will benefit from defining the requirements of the Experiment class a bit.

Keeps track of what tasks can be switched to (none while a task is running, when not running based on pre-requisites like subject selection). Manages streams which are persistent for the duration of a session (e.g. storage, input device).

Object that is persistent for the entire experimental session. Handles callback setting based on active task.

For hardware input devices, it would be good to have the device running all the time and the Experiment switches the callback to the current task, then the base task implementation waits until the second callback to emit data.

• Creates threads if needed.
• Defines what are the inputs and outputs
• Implementation for doing it (actual USB/serial/server communication).

• Need some experiment setup (storage layout)
• Receives messages to save
• Experimental setup, message documentation, and inter-experiment control (trial manager, etc) determine what and how is saved.

Specify a chunk of data that can be passed between blocks/IOstream/task.

Definitions of fieldname and data-type.

• Take in messages, do stuff, send messages.
• Specify what messages are received and sent
• Define what is done on receipt of message.
• Use axopy messaging API (which just calls backend API)

• Primarily serves as the API for connecting blocks/IOstream, setting up trials, etc.
• Can receive messages, i.e., timer ends trial.
• Prepare/cleanup connect/disconnect streams.
• How to get time-stamps for GUI and physical IO for trustworthy analysis?
• On start_trial (or run?) connect to callback initial receivers, that kicks off actual processing.
• Task (maybe mixins) provides callbacks for streams. For a hardware input stream that constantly emitting data, the connection to the tasks callback is made when the task is run. Ignore the first receive, then emit the data from the tasks signal. This means the user connects tasks signal (instead of the IOStream's signal) to its blocks.