Page Comparison

...

Sorted unit information (which electrode, which unique unit ID, color) are stored in the spike object that is passed on the pipeline. 

Network Events Source

The network event module source listens over the network on a specific port. Implementation is based on the widely used 0MQ library. 

Special commands will  be transferred to other modules (e.g. remote start/stop recording, etc).

The network event module sends incoming messages on the pipeline using the midi buffer, with a special NETWORK event code.

The network event is now implemented as a source. To use it, you'll need to add a merger module and link it to the main processing pipeline, preferably, before any other modulesTo add this capabilities to your graph, dump the network events, and then use the merger utility to merge the two streams.

Network events are useful for sending trial information or other text-based data to GUI (for example, sending updated position of advancers).

Commands can be send directly to a specific module using the reserved keyword "ProcessorCommunication". For example, one can send a string to a specific processor in the graph by sending the string "ProcessorCommunication <processor name> <command>". Processors evaluate incoming messages using the virtual function "interProcessorCommunication".

Special commands are also available:

1. "StartRecord", will cause the graph to start recording.
2. "StopRecord", will cause the graph to stop recording.
3. "SetSessionName <folder name>" will override the default directory where files are stored (from date-time) to <folder name>
4. "ProcessorCommunication" <processor name> <string command>, will send a command to s specific processor.

Peristimulus time histogram (PSTH) sink

The PSTH sink module has two main functions:

Image Added

A. It is used to display average firing rate and average lfp, aligned to external events, such as TTL pulses, or more complex trials that are sent over the network (e.g., in the snapshot above, you can see the peri stimulus time histogram for a specific trial type, triggered by a network event. Left most window is the LFP aligned to the trigger, while the yellow and green windows correspond to two isolated sorted units that were defined in the Spike Detector module).

B. It is used to save to disk all pipeline events that were generated after the source (i.e., network events, spikes, etc).

...

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:

...

An example how to send string messages to GUI from a c++ / matlab session will be available on github.

...

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