both the med associates and the coulbourn instruments systems can monitor multiple inputs and control multiple outputs . both can run multiple experiments concurrently with ease .
both require a windows - based system and really should be run on a dedicated computer that is not burdened by being connected to a network .
both offer a runtime screen that provides information about the status of the current experiment .
both systems are designed to be used with proprietary interfacing equipment available from the manufacturer .
the reader is urged to consult the manufacturers web sites ( www.coulinst.com and www.med-associates.com ) for detailed descriptions of the products .
i should note that i have received timely and helpful assistance from both companies when it was needed .
the user creates a text file consisting of statements written in medstate notation ( easily learned by a pascal programmer , challenging for the user with no programming experience ) .
this can be done using the editor provided with the system or with any editor or word processor capable of producing plain - text output .
the program can contain as many as 32 distinct state sets , each acting as an independent  mini - program . 
prior to use the program must be compiled , a process that will reveal coding errors that must be corrected before compilation can succeed .
once a program is successfully compiled it is available to be run from a pull - down menu within a separate med associates program .
medstate notation allows data to be stored in 26 variables ( labelled a to z ) , each of which can take the form of either a single variable or a 1-dimensional array .
these variables can store any data that the user specifies when the program is written .
for example , one might contain the total number of times that a lever was pressed , another might contain a list of inter - response latencies , and a third might indicate the number of  correct  responses .
although limiting the total number of variables to 26 might seem constraining , i have yet to find this too restrictive , especially because arrays are allowed .
the data are written to disk as a plain text file ; several formats are available for the data file , and the one selected will probably be determined by whether or not the file will be imported into a spreadsheet .
the programming window offers a picture of the front panel of the hardware that interfaces with the behavioral equipment . by pointing and clicking within this window
the user can can specify the stimuli to be turned on during each state , the responses or time events that cause the state to terminate , and the target state(s ) to be activated upon termination of the state .
for example , to turn on the houselight for 10 s , the programmer would click on the houselight button to toggle it on , and specify that the state should end after 10 s. the program must be written via the graphic state 2 programming interface , and the program is saved in a proprietary format that requires it to be viewed via graphic state 2 . because of this it is impossible to print the program for archival purposes .
once the program is constructed , gs2 performs a check to ensure that it contains no states that are not called by at least one other state or that fail to call another state  a check that helps to ensure that the program is at least likely to terminate . because the user writes no code , errors in programming syntax are far less likely than in med associates system .
graphic state 2 consists of a single state set ; that is , only a single state can be active at any given time , as compared to medstate notation s 32 concurrent states . usually counters and timers are reset when a new state is entered , but the program allows them to retain their values across states or throughout an entire session .
graphic state 2 logs all events while a session is being run , even if they have no effect on the program .
if a state is ended by a response on lever 1 , for example , the program will also log responses on lever 2 even if they do nothing .
the data file that is created contains a record of every response or state change that occurred during the session , with a record of the time during the session when the event occurred and an indication of the cause of each state change .
instead a record of the entire session is available at its conclusion for analysis by graphic state 2 s extensive library of analysis routines or for exporting as a text file .
without question , the easier of the two systems to learn to program is graphic state 2 . the point - and - click interface obviates the need to learn seemingly obscure programming language , and the fact that the program records everything that occurs during a session means that the user does not have to program variables to track relevant information .
indeed , a student with no programming experience watched me write a simple program one morning , and by the afternoon had mastered graphic state 2 well enough to write a program to control a two - lever autoshaping procedure . in comparison ,
it is true that the commands are reasonably intuitive ( e.g. ,  on  turns on a stimulus ) , but they must be learned and they must be entered correctly . furthermore , the user must specify and track all variables of interest ; the program will automatically record the values of variables a through z at the end of the session , but these values will be 0 unless the program contains code to update them ( e.g. , count responses in variable r , record number of trials in variable t , etc . ) .
the availability of only one state set within a graphic state 2 program makes some tasks either very difficult or perhaps impossible to program , especially those tasks that involve independent timing of various stimuli .
for example , consider the truly random control condition in a pavlovian conditioning study ( rescorla , 1967 ) .
the investigator wants a tone to turn on for 5 s and a feeder to operate for 0.1 s ; the two should occur perhaps 20 times each during a 30-min session , but totally randomly with respect to each other . in medstate notation
each could be controlled by its own state set , without any reference to or input from the other ( as if each stimulus was controlled by its own 1960s - era tape timer ) . in gs2 , because a stimulus can be turned on only by entry into a state , and because only a single state set is available , the two stimuli must of necessity be controlled together , and a complex program must be established consisting of states in which none is on , one is on , or both are on ; the durations of these states will be varied and complicated .
i think that the only way to implement this program in gs2 would be to create a fixed schedule of the two stimuli that simulates the random occurrence of both , then to program this fixed schedule .
a program in which the two stimuli occur truly randomly with respect to each other might well be impossible in gs2 .
gs2 creates a log of a session that contains every transition from one state to another ( because stimuli are tied to states this corresponds to a record of stimulus presentations ) and every response onset and offset ( whether the responses cause state transitions or not ) .
the result is a complete record of the session , available for export as a text file or for analysis within gs2 itself .
because the record of the session contains all responses that were available to be monitored the researcher can ask questions after the fact that were not anticipated at the time the session was run .
a large number of routines are provided by gs2 that allow extensive analysis of the data , including frequency of entry into each state , number of responses within each state , inter - response intervals , etc .
unfortunately the explanations of these routines are far from intuitive , and the routines seem geared toward free - operant schedules .
i run trial - based studies , often in runways or mazes , and the analyses have never been useful to me except as quick checks at the end of a session to ensure that data were recorded .
i have relied on the exported raw data text files , which i then filter extensively and analyze with a spreadsheet program ( e.g. , excel or gnumeric ) .
medstate notation s approach to data is far different : only the variables specified by the programmer are recorded ; there will be no record of the number of responses if the program does not contain a counter that is incremented with each occurrence of the response .
medstate notation allows data to be saved in text files in a limited number of formats , some human friendly and some ( supposedly ) spreadsheet friendly .
the text - files must be manipulated extensively with a spreadsheet before useful analysis can occur .
med associates offer an additional program called mpc2xl to ease translation from their data files to a spreadsheet ; i have no experience with it .
although both medstate notation and gs2 data files could be made far more user - friendly in terms of how data are formatted for subsequent use by spreadsheet programs , i find medstate notation s files easier to use .
they are inherently smaller , because they contain only those data that i have requested .
because i can specify counters , timers , and other variables in the program , the data file contains the information that i want with very little further analysis , for example , some of my behavioral routines allow rats to control the onset of their own pavlovian trials , and the number of trials initiated is a critical dependent variable .
a variable within a medstate notation program can record this number as the session runs , display it on the screen , and save it in the data file . in gs2
this variable would correspond to the number of times a particular state is entered ; there is no way to display this , but instead an analysis must be run on the data at the conclusion of the session . the ability to create user - defined variables that track meaningful information , and to display these variables as they are updated during the session , make a medstate notation session far more informative than a session run in gs2 .
a well - designed medstate notation screen can provide all of the data of interest at the end of a session .
gs2 sessions are likely to require post - session analysis in order to get even the most rudimentary of data .
med associates medstate notation and coulbourn instruments graphic state 2 both offer the scientist useful tools for behavioral research .
gs2 s strengths lie in its user - friendly programming interface and its many analytical routines . for the non - programming scientist
medstate notation , with the availability of multiple concurrent state sets , offers a far more powerful programming environment . the time spent in mastering medstate notation
i believe that the serious behavioral scientist is better served by the med associates product .
 two of the most widely used programs for the control of behavioral experiments are med associates medstate notation and coulbourn instruments graphic state 2 . 
 the two systems vary considerably in their approach to programming and data recording , with graphic state 2 using a point - and - click interface that appeals to non - programmers while medstate notation requires the typing of programming code . 
 graphic state 2 provides many data analysis routines , while medstate notation allows the user to embed simple data analysis within the behavioral protocol . 
 graphic state 2 is simpler to use , but medstate notation is more versatile . 
OVERVIEW OF THE SYSTEMS
PROGRAMMING EASE AND VERSATILLITY
DATA FILES AND ANALYSIS
CONCLUSION