2.6 Interactive Simulation



Figure 13 -- VCR Interface

The interactive simulation is controlled by the VCR interface located at the bottom of the application window. The VCR interface consists of buttons (whose basic functions are derived from the functions of a VCR -- hence the name) with pixmap images and text captions of the corresponding functions on their fronts. During creation, callbacks are registered for each button to test the present function and then implement the corresponding desired action. A state machine model was implemented to coordinate the actions.

The state machine simply consists of a list of possible states and an application wide variable used to keep track of the current state. When the user presses a VCR button, the corresponding hook checks the current state and determines if the next state is valid for the desired action. If it is, the next state requested becomes the current state then the desired action is executed. In most cases this means that a procedure is invoked and runs to completion, or, in the case of a computationally intensive procedure, the procedure is registered as a work procedure and executes n times before checking for the presence of an event in the event queue then calls the procedure again until completion of the requested task. If the desired next state is not valid, the request is simply ignored and the hook function simply returns. For example, if the current state is NO_FILE (indicating that no data file has yet been processed), then no user selection from the VCR interface will be valid so any button selected will simply call its hook function, see that it is an invalid next state and return with no alteration to the state machine.

The states are defined in playerst.h as follows:

The unusual numeric constants are in anticipation of a future speed up to be gained by bit masking to determine the current and next states rather than variable comparison. If the next state is valid it becomes the current state. At the time of change, the desired procedure is called.

2.6.1 Updating a Time Step


The interactive simulation uses the data structures created during the numerical simulation to produce a visualization of the current time step. To generate it, the values to represent the z-axis values in the threshold mesh located in the two dimensional global array treeLeaves[NUMBER OF TOTAL POPULATIONS].vertices[10][10] are updated with the values in the global array active_neurons[Framing.time_step].f->threshold[][]. Likewise the values to represent the z-axis values in the potential mesh located in the two dimensional global array treeLeaves[NUMBER OF TOTAL POPULATIONS].vertices2[10][10] are updated with the values in the global array active_neurons[Framing.time_step].f->potential[][]. Since only a limited number of values in the spike mesh are updated on each time step, a separate data structure, a linked list, holds the Boolean values of the spike fields. The values to represent the z-axis values in the spike mesh located in the two dimensional global array treeLeaves[NUMBER OF TOTAL POPULATIONS].vertices3[10][10] are updated with the values represented in the linked list active_neurons[Framing.time_step].firing_step. The values that are not represented in the list are replaced with zeros in the array. The 3-vector coordinates for the meshes in the scene graph must then be updated (Inventor apparently makes its own copy that must be updated) with a call to treeLeaves[k].meshCoords3->point.setValues(0, 100, treeLeaves[k].vertices3). After all the substitutions are made Inventor is forced to redraw its drawing area, the time step widget is updated and the procedure exits or begins again depending on the current state.

2.6.2 REST_STATE State


The rest state indictates there is no other current state and the application is just waiting. It is only invoked when a valid data file has been run through the numerical simulation and no other data file is being processed. This state is the natural successor to all of the states that involva a traversal of the storage structure.

2.6.3 PLAY State


At the initiation of the PLAY state, the current time step is incremented and the procedure described in "Updating a Time Step " runs to completion. A call to select(0,0,0,0, &timeInterval) forces the application to wait for the value held at the location pointed to by timeInterval milliseconds and then the whole operation repeats. The time step is incremented and the display is updated until the last time step in the recording is reached. At this time the state is updated to REST_STATE.

2.6.4 FF State


At the initiation of the FF state, the currrent time step is incremented and the procedure described in "Updating a Time Step " runs to completion. User input is checked by way of the work procedure method described in the Callbacks section and then the whole operation repeats. The time step is incremented and the display is updated until the last time step in the recording is reached. At this time the state is updated to REST_STATE.

2.6.5 REWIND State


At the initiation of the REWIND state, the currrent time step is decremented and the procedure described in "Updating a Time Step " runs to completion. User input is checked by way of the work procedure method described in the Callbacks section and then the whole operation repeats. The time step is decremented and the display is updated until the first time step in the recording is reached. At this time the state is updated to REST_STATE.

2.6.6 PAUSE State


At the initiation of the PAUSE state, the current state changes to PAUSE and the calling procedure is exited. When the execution of the previous attempts to resume, the hook sees that it is no longer in the correct state and returns immediately with a value of TRUE indicating that it is to be taken off of work procedure list. This effectively ends the execution of any previous state. If the previous state was not a traversal state then there is no further change other than the previously changed state variable. Example: The application is "playing" the simulation (it is in the PLAY state). When the user clicks on the pause button, the event will be placed on the event queue. When the play work procedure finishes its iteration, it return FALSE because it has not yet reached the last recording time step. Xt sees that the work procedure returned FALSE and decides that the work procedure will be called again. Before calling the procedure, all the events in the event queue are processed. Xt will see that a callback for a click on the pause button has previously been registered and will call the coresponding procedure. The pause button callback procedure simply changes the current state variable to PAUSE and exits. After processing all remaining events the event queue will be empty and Xt will call the play work procedure again. The play work procedure will check for a valid state before any further processing. Since PAUSE is not a valid state in the PLAY work procedure it will exit with a value of TRUE indicating that it has executed to completion. (Only a state of PLAY is valid in a the play work procedure.) Xt will see that a value of TRUE has been returned and will remove the procedure from its work procedure list. At this point, the event checking loop XtAppMainLoop is returned to and normal event checking and processing resumes. The application is now in the PAUSE state.

2.6.7 STOP State


The STOP state simply duplicates the functionality of the PAUSE state. It is implemented in anticipation of future extention to the functionality of the VCR interface.

2.6.8 RESTART State


At the initiation of the RESTART state, the currrent time step is set to the beginning time step of the recording and the procedure described in "Updating a Time Step" runs to completion. At this time the state is updated to REST_STATE.

2.6.9 REV_STEP State


At the initiation of the REV_STEP state, the currrent time step is decremented and the procedure described in "Updating a Time Step" runs to completion. At this time the state is updated to REST_STATE.

2.6.10 FF_STEP State


At the initiation of the FF_STEP state, the current time step is incremented and the procedure runs to completion as described in "Updating a Time Step." At this time the state is updated to REST_STATE.

2.6.11 NO_FILE State


At the initialization of the application, the state machine is placed in the NO_FILE state. This indicates that no data file has been run through the numerical state. When the user selects a file, it is processed, and the data structures are built and the application passes into the REST_STATE. During the life of the application it will never return to the NO_FILE state.


Figure 14 -- State Diagram fo Interface State Machine

Back to the Table of Contents
Next Section ->