Page Comparison

...

1. ClearDesign
   1. This command clears up all known conditions
2. NewDesign <design name>
   1. This command clears up all known conditions, and set up a name for the active "design". A design has any number of conditions. A condition has any number of trial types, and specific outcomes. See more below.
3. AddCondition Name <condition name> TrialTypes <trial types> Outcomes <trial outcomes> Color <R G B> Visible <visibility> SpatialPosition <X Y> Group <group>
   
   1. This command add a new condition to the active design. The condition will average spike & lfp information only for trials that belong to the subset of trials defined in <trial types>. 
   2. A trial type is any positive integer smaller than 30,000. Values above 30,000 are reserved for TTL trials that are automatically generated.
   3. You can further define whether to average a trial or not by its outcome. Outcomes can correspond to correct/incorrect, or any other response the animal makes. 
   4. Outcomes can be any positive integer.
   5. Color optional, and given by R,G,B, ranging between 0 and 255.
   6. Default visibility is optional. Visibility value is either 0 or 1, and will determine if this condition is visible by default, or whether the user needs to click on the GUI to make it appear.
   7. Conditions may have a optional 2D spatial position. This is useful when visual stimulation is delivered at a specific location on the monitor (i.e., saccade to a specific location trials).
   8. Conditions may be grouped together for easier visualization. For example, you might group a bunch of trials types with no stimulation together and compare them to trials that do get stimulation. Visualization in the future will be able to display them as two curves / rose plots / ... 
4. TrialStart <trial type, optional> 
   1. This command indicates that a trial has started. You can send (optionally) the trial type here as well. Otherwise, use the TrialType command
5. TrialType <trial type>
   1. This command sends the trial type information of the current running trial.
6. TrialAlign
   1. Spikes & LFP can be aligned not only to trial onset, but to other events (i.e., saccades, lever presses, etc). Use this command to indicate that firing rate should be aligned to the specific time point when this command was arrived.
   2. If TrialAlign command is not sent for a trial, the default is to average things relative to TrialStart
7. TrialOutcome <trial outcome>
   1. This commands indicate the outcome of the trial.
8. TrialEnd <trial outcome, optional>
   1. This indicates that a trial has finished, with the optional parameter that indicates what was the outcome.
9. DropOutcomes <trial outcome codes>
   1. This will indicate that all trials (regardless of their type) should be dropped and not analyzed if their outcome match the given list. Useful to drop trials in which the animal wasn't looking at the screen.
      
      

For example, a two alternative force choice task, with four conditions can be constructed like this:

...

1. Event type (uint8) which can have one of the following types:
   1. SESSION (code 10)
      1. This will inform that a new recording session has started /stopped
   2. TTL (code 3)
      1. This will inform that a digital signal went up/down
   3. NETWORK (code 7)
      1. This will inform of a string message arrived via Ethernet
   4. SPIKE (code 4)
      1. This will inform of a detected spike
   5. TIMESTAMP (code 0)
      1. This will save a pair of software & hardware timestamps, to allow synchornization between software events and hardware events.
   6. EYE_POSITION (code 8)
      1. This will inform that a new eye position signal has arrived. 
2. Event size (uint16)
3. Event specific data (variable length)
   1. SESSION
      1. uint8, representing whether a session has started (value = 1) or stopped (value = 0)
      2. uint16, representing recording session number
      3. int64, representing a software timestamp
   2. TTL
      1. uint8, representing whether the signal went up (value = 1), or down (value = 0)
      2. uint16, representing the channel number that was raised/lowered.
      3. int64, software timestamp
      4. int64, hardware timestamp
   3. NETWORK
      1. <variable length>, representing the incoming message. length of the message is the event size - 8
      2. int64, software timestamp
   4. SPIKE
      1. int64, software timestamp
      2. int64, hardware timestamp
      3. int16, sorted unit ID number
      4. int16, electrode ID number
      5. int16, number of channels in electrode (typically, 1, 2, or 4)
      6. float x number of channels: channel gain 
      7. int16, number of points in each channel (typically 32+8).
      8. <variable length>, representing the spike wave form. actual size will depend on the previous two numbers.
   5. TIMESTAMP
      1. int64, software timestamp
      2. int64, hardware timestamp
   6. EYE_POSITION
      1. double, x position
      2. double, y position
      3. double, pupil diameter
      4. int64, software timestamp
      5. int64, hardware timestamp
         
         
         

...