TWiki> BrainStreamDocs Web>BrainStreamDocs? >DocsSectionsBuildingExperiments (revision 5)EditAttach

Building Experiments

An experiment in BrainStream consists of experiment definition tables, which in some instances might contain user defined functions, block files and common block files. The entire experiment is summarized in the BrainStream Project file. In the following, each of these components will be discussed.

Experiment definition tables

The experiment definition tables (.edt) form the core of your BCI experiment. In these tables is specified which actions need to be executed at what time. For each experiment, three different tables are needed: the Actions table, the DataSelection table and the Dictionary table. Together, the experiment definition tables are called the experiment definition file. Brainstream has its own internal editor for creating the tables, however, for backwards compatibility reasons it also supports excel files (.xls extensions only) where each table is put in a different sheet, or a set of separate text files (.txt), one for each table. In the following, the experiment definition tables will be discussed in more detail.

Actions table

Table 1 is an example of an Actions table:

marker time function feval looptick client var1 ........ varN
mrk1 EVENT fnc1,fnc2       get,put ........ $self+1
mrk2 2 fnc3       [],put ........ get,put

Table 1: Actions table

The first three columns in an Actions table are reserved to specify marker, time, and function. The three following columns feval, looptick, and client are optional and will be discussed later. Although the order of these first columns in the table is arbitrary, it is best to keep it as described here. All subsequent columns are free to use for an arbitrary number of user defined variables (stored internally in BrainStream's user state, i.e. the global variables).

The first column of the Actions table, the marker column, contains the names of all markers that elicit the execution of certain actions. For example, marker mrk1 in table 1 could mark a response made by the participant. Perhaps the experimenter wants the response to be followed by feedback about the response. In that case, marker mrk1 should be in the marker column of the actions table.

The second column (time) specifies at which timepoints, relative to the time of the incoming marker, actions should be executed. The exact timing of execution can be specified in several ways. The action can be executed directly at marker onset, when a certain amount of data becomes available, some time after the marker, or when another marker arrives (see table 2). For example, table 1 specifies that some actions are executed at the onset of marker mrk1 whereas other actions take place two seconds after marker mrk2.

EVENT
DATA
a number
another mrk
Executed at marker onset
Executed as data becomes available
Executed number seconds after marker onset
Executed at onset of marker mrk

Table 2: Specifying time of action execution

The third column (function) can contain one or more functions that will be executed in the order in which they appear in the table. So, in table 1, at the onset of marker mrk1, first function fnc1 and then function fnc2 will be executed. Two seconds after the onset of marker mrk2, fnc3 will be executed. A number of BrainStream functions can be specified in the function column. Alternatively, you can write your own user defined functions, which will be discussed in detail below.

The next three columns are optional. The feval column allows for specification of any functions that do not need to process any of the global variables and do not return output arguments, but can take global variables as input argument. The looptick column is optional and serves to define a special function that always executes on another client and will be put into a loop by BrainStream, click here for more information on how to use this. The client column can be used to direct execution of functions to another remote Matlab session (see Running BrainStream in Parallel Mode.

All subsequent columns are free to use for an arbitrary number of user defined variables (more on this later).

DataSelection table

Sometimes a marker signals a time point around which data should be collected. For example, if you are building an ERP-based BCI, you might want to collect a certain amount of data after each stimulus. For that purpose, each marker can specify a segment of data that should come along with the event. The DataSelection table indicates which markers call for data selection and also the time period of data collection relative to marker onset.

The DataSelection table consists of a marker column, a begindata column, and an enddata column. Data selection may start before or after onset of the marker, indicated by negative and positive numbers respectively. The end of data selection can again be before or after the onset of the marker specified in the marker column, or you can use a new incoming marker by entering the name of the new marker (with or without extra timing). If multiple endtimes, seperated by a comma, are specified, the one that happens first will end the data selection.

marker begintime endtime datasource
mrk1 -0.5 2  
mrk2 0.5 mrk3  
mrk3 0 mrk3, mrk4  

Table 3: DataSelection table

The table above shows an example of a data selection table. The data selection of mrk1 will start half a second before onset of the marker and end 2 seconds after the onset.The data selection of mrk2 will start half a second after the onset of mrk2 and will end when the new marker mrk3 arrives. mrk3 will start data selection immediately and this will end when a new marker mrk3 or the marker mrk4 arrives. For more examples of this data selection timing see Data-carrying events in the Architecture section.

The datasource column is optional. If multiple data sources are used in the experiment, the datasource column specifies from which source the data should be collected. If only one data source is involved, BrainStream will automatically collect data from this single source only.

Dictionary table

Markers are represented as numbers in for example the acquisition hardware or stimulus presentation modules, whereas in BrainStream they are represented as names (strings). The Dictionary table is required to translate incoming markers to their associated names.

The first three columns of the Dictionary table are fixed. In the marker column the marker names are specified. The second column (type) column specifies the marker type. The marker can for example be a stimulus or a response marker. The value column specifies the number with which the marker is represented outside BrainStream.

The substitute and datasource columns are optional. More information about the substitute column can be found in the Plug-in section. If multiple data sources are used in the experiment, the datasource column specifies for which data source the dictionary information is meant. If only one datasource is involved, this column can be left out and BrainStream will apply the definitions to the single data source.

marker type value substitute datasource
tone stimulus 10    
voice stimulus 11    
button response 128    

Table 4: Dictionary table

Plug-in tables

BrainStream supports the use of Plug-in tables. An example of a plug-in table is the plug-in for [BrainStreamDocs.DocsSectionsApplications#SeqBadChan][bad channel detection]]. Alternatively, it is possible to build your own plug-in table. Any plug-in itself consists of an Action, DataSelection and Dictionary table.

When BrainStream is started, all experiment definition tables that are used in the experiment - including the plug-in tables - are combined in a process called table expansion. This means that all Action tables will be integrated into a single Action table, and the same is true for the DataSelection and Dictionary tables. Importantly, the information in the individual tables shoud not conflict. For example, you should prevent double definitions of marker names or numbers.

User defined functions and variables

In the Actions table, certain actions are assigned to markers. You can define the actions directly in the table, but it is also possible to specify actions by adding user defined functions to your table. The functions that you write may need certain variables as input. An arbitrary number of columns in the Action table can be used for these user defined variables.

If a function needs a user defined variable, you first need to get it from the global variables. This is done by putting a ‘get’ statement in the corresponding cell. For example, consider the following Actions table:

marker time function feval looptick client var1 ........ varN
mrk1 EVENT my_fnc1       get ........  
mrk2 2 my_fnc2         ........ get,put

At the onset of marker mrk1, user defined function my_fnc1 will be executed. This user defined function needs the user defined variable var1 as input. In order to make this variable available to my_fnc1, a 'get' statement is placed in the var1 column. Note that variable var1 is not available to the user defined function my_fnc2 that is executed after marker mrk2, as no 'get' statement is present in the var1 column after this function.

User defined functions must be written in the following format:

event = my_function(event,c1,c2,...)

The input and output argument 'event' is obligatory. Event is a Matlab type structure variable. The fields of this structure contain copies of the current content of the variables with a 'get' statement in the table. In the above example, var1 was made available to function my_fnc1 with a 'get' statement. Thus, the my_fnc1 input argument 'event' will contain the field event.var1, which holds a copy of var1. In contrast, the input argument 'event' of function my_fnc2 will not contain the field event.var1 (no 'get' statement in the Actions table), but it will have a field called event.varN, which contains a copy of variable varN.
The additional input arguments (c1, c2, ...) are optional. You can enter constants there, if your function needs them.

Your user defined function might change the content of some the variables you use as input. If you want to save these changes, you can place a 'put' statement in the corresponding cell in the Actions table, which updates the modified variables to the global variables. In the example above, changes that my_fnc2 makes to varN are saved, but changes that my_fnc1 makes to var1 are not (no 'put' statement). For more information about loading, modifying and saving user defined variables, see Modifying variables.

Block files and common block files

To initiate your experiment in BrainStream, you need to compose an initialization run file(s), also called a block file (.blk). Every block has a separate file, which contains or refers to all information needed to initiate the particular block. For example, BrainStream needs to know to which data acquisition source it is connected, where to store output and where the experiment definition tables are located. All this information can be summarized in a text file with file name extension .blk. The format of the file is according to the Windows .ini file style with topics enclosed in brackets and subsequent lines to define keys that belong to this topic. If another bracketed line is encountered, a new topic is started and additional lines will add keys to this new topic. The notation of the topics and keys is in Matlab style, which means that every valid Matlab statement is possible here. For example, Matlabs comment character (%) can be utilized. An example of a block file is shown below. In this example, all minimally required topics with their keys are shown.

[DataSources]
eeg = 'buffer://localhost:1972:biosemi_active2'

[eeg]
% keys specific to the eeg data source 

[biosemi_active2] 
sendMarkerFunction = 'sndMidiMarker'

[Files]
ExperimentDefinitionFile = '/Volumes/Data/ExpDefs/SubRhythm/SubjectiveRhythm.xls'
OutFolder = '/Volumes/Data/Experiment/'

[Experiment]
Block = 'subjective_rhythm'

Additional possible topics with their keys are listed here? .

In addition to the listed topics and keys you can add your own topics and keys, as long as they are not used by BrainStream itself. The advantage is that these items are readily accessible for your own written user defined functions throughout the whole experiment. Information in the block files can be accessed using the bs_get_blockvalue function.

If an experiment consists of several blocks, the topic and key combinations which are the same for all blocks can be put in a common block file. For example, information that is specific to the lab in which the experiment takes place could be put in a common block file. The advantage is that you do not have to specify the same information more than once and if you change the setting in the common block file it will be applied to all blocks.

BrainStream project files

References to all block files and common block files can be put together in a single seperate 'BrainStream Project' (.bsp, or .exp for older versions) file with topics Blocks and CommonBlocks. Both topics define the Files key, in which a cell array of block file names defines which block files take part in the experiment. This single file then defines your whole BCI experiment. For example, if your experiment is defined by three functional blocks, namely train.blk, classifier.blk and feedback.blk, and one common block file lab1.blk, the following project file would be sufficient to include them all at once when starting BrainStream:

[Blocks]
Files = {'/Volumes/my_experiments/my_BCI/train.blk', ...
         '/Volumes/my_experiments/my_BCI/classifier.blk', ...
         '/Volumes/my_experiments/my_BCI/feedback.blk'}
[CommonBlocks]
Files = {'lab1.blk'}  
Edit | Attach | Print version | History: r35 | r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 22 Sep 2011 - 10:27:25 - MarjoleinVanDerWaal
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback