Fall 2010

Handles setting up the StreamManagers and their connections to input (wiimotes/audio).

Wrapper that controls the connection into the cloud.   Communicates with the control process and feature extractor by sending packets up into the cloud.  Contains a module for converting input stream to data that is going to be sent.

Communicates with control process and acts as a view into it.

Exists on the client PC connected to what ever is doing the display.  Recieves messages from the view adapater in the cloud in the form of drawing commands.  Processes the message from the view adapter and does the graphics rendering.

 

Communicates with the control process to inform it of what commands it is responsive to, and the parameters to those commands.

Listens for incoming connections from new streams.  Upon recieving a new connection request, communicates with the control panel to figure out what to do with the new stream, and sets up the feature extractor.  Responsible for setting up the appropriate number of mixers and their network topology.  Keeps a mapping of streams to feature extractors.  Responsible for keeping track of status updates from all feature extractors, mixers, and view adapters. Also for determining what features will be extracted from a data stream and how those features will be visualized. Once all Mixer Role Instances and View Adapter Role Instances report ready, tells all Stream Managers to start sending data.

 

There will be two instances of the Control Process Role running, with one being designated Main. The other instance will forward all connections to the Main instance so that it may keep the initialization synchronized. Should the Main instance fail, the secondary instance will assume the role of Main.

 

On detecting a new connection from a Stream Manager, queries the State Repository for the appropriate template. Sets up the appropriate Feature Extractor and connections to the appropriate Mixer Role Instance and View Adapter Instance as defined in the template.

 

Each instance listens for and accepts connections from Feature Extractor Role Instances then queries State Repository for the list of subgraphs it is responsible for, generates the approriate Mixers, matches incoming connections to mixers, sends out outgoing connections to other Mixer Role Instances or View Adapter Role instances as defined in the subgraphs. Once all connections are accepted and all Mixers initialized, communicates a ready message to the Control Process Role.

 

Does feature extraction on the data stream of the associated Stream Manager, generates events based on those features which it communicates to the appropriate Mixer or directly to the View Adapter. This is a 1 to N communcations module.

 

Mixer

Takes in events from feature extractors or other Mixers and applies a transformation rule to these events based on some time difference tolerance to generate new events and forwards those to the next module in the event graph. It also acts as an implicit synchronization barrier. The receiving modules could either be other Mixers or View Adapters. This is an 2 to N communications module. The processing for a mixer is done a a lambda that is entered on construction. This lambda is bound to the predefined events.

Events

These are the messages between feature extractors, mixers and view adapters. The Event message has a name, timestamp and payload, which is a list of elements. An element is an id and a payload.

Takes in events from Mixers or Feature Extractors and applies transformation rules to generate commands for a specific Display or group of Displays. The commands serve as a hardware abstraction layer.

 

The VA forms a barrier from the cloud to the Display. It pushes messages to synced displays organized in groups, where each group is a set of displays that respond to and interpret events in the same way (ie. generate the same set of commands for a set of events). These ViewGroups reduce the redundant computation involved in translating an event to its command for a display so that large groups of displays can be managed and synced. It also allows displays to be moved around from group to group (provided the groups are generating events the display understands) to dynamically reconfigure what events a display responding to without having to remap the event handlers.