Difference: DocsSectionsImportantConcepts (1 vs. 25)

Revision 2517 Nov 2014 - Main.PhilipVanDenBroek

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 7 to 7
 
Added:
>
>

Introduction

BrainStream essentially is an event handler, which events are different in the sense that execution of corresponding actions can optionally be distributed over multiple timepoints, i.e., discrete moments in time. The execution of these timepoints again can be distributed over different computers, which implies processed events can both be distributed in space (parallel) and in time. BrainStream incorporates special features to automatically guarantee a correct parallel processing of information by letting users exactly specify what information is required for each event.
 

Markers

Revision 2414 Nov 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="BrainStream.BrainStreamDocs"
>
>
META TOPICPARENT name="WebHome"
 
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 10 to 10
 

Markers

Changed:
<
<
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control the insertion of markers and specify the actions associated with them.
>
>
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control the insertion of markers and specify the actions associated with them.
  Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.

Revision 2314 Nov 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="BrainStreamDocs"
>
>
META TOPICPARENT name="BrainStream.BrainStreamDocs"
 
<---Start1--->

Important concepts: Markers, Events and Global Variables

Changed:
<
<
Generate current PDF
>
>
Generate current PDF
 

Markers

Changed:
<
<
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control the insertion of markers and specify the actions associated with them.
>
>
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control the insertion of markers and specify the actions associated with them.
 
Changed:
<
<
Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.
>
>
Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.
  There are different marker types, for example stimulus, response and device control markers. Marker name, number, and type combinations are stored in Dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
Line: 91 to 91
 
META FILEATTACHMENT attachment="Event1.png" attr="" comment="" date="1319014318" name="Event1.png" path="Event1.png" size="78844" stream="Event1.png" tmpFilename="/var/tmp/CGItemp46457" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Event2.png" attr="" comment="" date="1319014326" name="Event2.png" path="Event2.png" size="121220" stream="Event2.png" tmpFilename="/var/tmp/CGItemp46519" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="GlobalVars1.png" attr="" comment="" date="1319016336" name="GlobalVars1.png" path="GlobalVars1.png" size="164640" stream="GlobalVars1.png" tmpFilename="/var/tmp/CGItemp46540" user="MarjoleinVanDerWaal" version="1"
Changed:
<
<
META TOPICMOVED by="MarjoleinVanDerWaal" date="1317049480" from="BrainStream.DocsSectionsBSArchitecture" to="BrainStream.DocsSectionsImportantConcepts"
>
>
META TOPICMOVED by="MarjoleinVanDerWaal" date="1321263643" from="BrainStream.DocsSectionsImportantConcepts" to="BrainStreamDocs.DocsSectionsImportantConcepts"

Revision 2209 Nov 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 10 to 10
 

Markers

Changed:
<
<
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control both the insertion of markers and the actions associated with them.
>
>
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control the insertion of markers and specify the actions associated with them.
  Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.
Line: 34 to 34
  Figure 2: Events end when all associated actions have been executed
Changed:
<
<
Thus, the scope of events can range from a single processing step to very complicated processing pipelines. Especially in more complex cases, events may contain a lot of information, for example a list of which actions must be executed at which timepoints, variables associated with the actions, and data that has been collected during the event. All this information is organized in a Matlab struct variable with the name event. This structure contains a number of fixed fields and may contain additional fields depending on the experiment. For more detailed information see Fields of the Event Structure.
>
>
Thus, the scope of events can range from a single processing step to very complicated processing pipelines. Especially in more complex cases, events may contain a lot of information, for example a list of which actions must be executed at which timepoints, variables associated with the actions, and data that has been collected during the event. All this information is organized in a Matlab structure variable with the name event. This structure contains a number of fixed fields and may contain additional fields depending on the experiment. For more detailed information see Fields of the Event Structure.
  Within an event, information can be transferred from one action to another via the event structure. For example, take a look at Event 2 in figure 1. Let's assume that action 1 adds a variable Var1 to the event structure, in the field event.Var1: event.Var1 = 3. During action 2, this variable is modified, so that event.Var1 = 4. If Var1 is used for performing action 3, the change that was made by action 2 will be incorporated. However, the event structure has a limited lifetime: it only exists for the duration of the event. When action 3 is completed, the event structure associated with Event 2 disappears. Var1 and the change that action 2 made to it will not be transferred to later events, for example Event 3. Thus, we cannot transfer information between events via the event structure. For this, we must use global variables.

Revision 2120 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 52 to 52
 

Retrieving and updating content of global variables

Changed:
<
<
The statements 'get' and 'put' in the Actions table control the exchange of variable content between the global variables and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the global variables into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the global variables.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
>
>
The statements 'get' and 'put' in the Actions table control the exchange of variable content between the global variables and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the global variables into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the global variables.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
  As all these actions take time, it is advisable to perform them only when needed (for example, do not copy variables into the event structure that are not used during the current event).

Revision 2019 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 22 to 22
 

Events

Changed:
<
<
Every marker that is received by BrainStream, instantiates a new event. During an event, one or more actions can be executed at one or more different timepoints. Possible actions are modifying variables, executing functions or collecting data. An event ends when all actions that are specified for this event have been executed. A timeline with 3 events is show below:
>
>
Every marker that is received by BrainStream instantiates a new event. During an event, one or more actions can be executed at one or more different timepoints. Possible actions are modifying variables, executing functions or collecting data. An event ends when all actions that are specified for this event have been executed. A timeline with 3 events is show below:
  Event1.png

Revision 1919 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 22 to 22
 

Events

Changed:
<
<
Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded as objects with actions, data (optional), and variables. To some extent, it can be compared to the OOP (object oriented programming) concept. An event consists of the following:
>
>
Every marker that is received by BrainStream, instantiates a new event. During an event, one or more actions can be executed at one or more different timepoints. Possible actions are modifying variables, executing functions or collecting data. An event ends when all actions that are specified for this event have been executed. A timeline with 3 events is show below:
 
Changed:
<
<
event
name (= name of the marker that instantiates the event)
time points
EVENT
DATA
time delay in seconds
another marker
For marker sequences, MRKSEQ and TIMEOUT can be used as timepoints
actions (loading, modifying or saving variables and executing functions)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session (see Parallel Mode).
data selection (optional)
Any marker can trigger the selection of a certain amount of data.
>
>
Event1.png
 
Changed:
<
<
Thus, an event is completely defined by the specification of actions at specific time points and optionally the amount of data that should come with it. Any combination of an action and a certain time point can only be defined once. In addition, for every processing step can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can potentially be executed at another Matlab session (i.e., a client).
>
>
Figure 1: Three events
 
Changed:
<
<
Event objects exist until all their associated actions have been handled. Events can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list.
>
>
Event 1 begins when marker mrk1 arrives. During Event 1, only one action is executed. The event ends when this execution is complete. Markers mrk2 and mrk3 start Event 2 and Event 3, respectively. For Events 2 and 3, multiple actions and timepoints are specified. These events end when all actions associated with them have been executed.
 
Changed:
<
<
For a more detailed description of the event structure, see Fields of the Event Structure.
>
>
Event2.png
 
Changed:
<
<

Actions associated with an event

During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The Actions table specifies which actions should be executed for each event.
>
>
Figure 2: Events end when all associated actions have been executed
 
Changed:
<
<
BrainSream always executes actions in a fixed order, based on their position in the table and the type of action. Click here for more information on the order of action execution.
>
>
Thus, the scope of events can range from a single processing step to very complicated processing pipelines. Especially in more complex cases, events may contain a lot of information, for example a list of which actions must be executed at which timepoints, variables associated with the actions, and data that has been collected during the event. All this information is organized in a Matlab struct variable with the name event. This structure contains a number of fixed fields and may contain additional fields depending on the experiment. For more detailed information see Fields of the Event Structure.
 
Changed:
<
<

Data associated with an event

Each marker may specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a DataSelection table.
The selected data can be found in the event field event.data.raw.
>
>
Within an event, information can be transferred from one action to another via the event structure. For example, take a look at Event 2 in figure 1. Let's assume that action 1 adds a variable Var1 to the event structure, in the field event.Var1: event.Var1 = 3. During action 2, this variable is modified, so that event.Var1 = 4. If Var1 is used for performing action 3, the change that was made by action 2 will be incorporated. However, the event structure has a limited lifetime: it only exists for the duration of the event. When action 3 is completed, the event structure associated with Event 2 disappears. Var1 and the change that action 2 made to it will not be transferred to later events, for example Event 3. Thus, we cannot transfer information between events via the event structure. For this, we must use global variables.
 

Global variables (user state)

Changed:
<
<
Within a processing pipeline (i.e. within a single event), information between different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables, also called the user state. Users can choose any name they want for their variables, except the set of reserved variable names that are already used by BrainStream. The actions of getting the content of variables from the global variables or updating modified variable content to the global variables must be explicitly defined in the experiment definition tables. Variables are then copied from the global variables into the event structure, so that the variables are only accessible for the duration of the event.
>
>
Within events, information between different processing steps is preserved. However, different events can only exchange information via a set of globally maintained variables, also called the user state.

GlobalVars1.png

Figure 3: Information exchange between events via the global variables

During events, variables can be retrieved from the global variables. Their content is copied into fields of the event structure with the name of the variable, for example the content of Var1 will be copied into event.Var1. The variables are then available in the event structure for the duration of the event. When the event ends, the (modified) content of the variables can be updated from the event structure to the global variables. Later events can retrieve the modified content of the variables and place it in their own event structure. Thus, information can be transferred between events via the global variables.

 
Changed:
<
<

Getting and storing content of variables

>
>

Retrieving and updating content of global variables

  The statements 'get' and 'put' in the Actions table control the exchange of variable content between the global variables and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the global variables into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the global variables.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.

As all these actions take time, it is advisable to perform them only when needed (for example, do not copy variables into the event structure that are not used during the current event).

Line: 88 to 88
 
META FILEATTACHMENT attachment="Slide_table_2.png" attr="" comment="" date="1316782771" name="Slide_table_2.png" path="Slide_table_2.png" size="35468" stream="Slide_table_2.png" tmpFilename="/var/tmp/CGItemp43991" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Slide_block_2.png" attr="" comment="" date="1316783090" name="Slide_block_2.png" path="Slide_block_2.png" size="37624" stream="Slide_block_2.png" tmpFilename="/var/tmp/CGItemp43913" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Slide_experiment_2.png" attr="" comment="" date="1316783558" name="Slide_experiment_2.png" path="Slide_experiment_2.png" size="62491" stream="Slide_experiment_2.png" tmpFilename="/var/tmp/CGItemp43909" user="MarjoleinVanDerWaal" version="1"
Added:
>
>
META FILEATTACHMENT attachment="Event1.png" attr="" comment="" date="1319014318" name="Event1.png" path="Event1.png" size="78844" stream="Event1.png" tmpFilename="/var/tmp/CGItemp46457" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Event2.png" attr="" comment="" date="1319014326" name="Event2.png" path="Event2.png" size="121220" stream="Event2.png" tmpFilename="/var/tmp/CGItemp46519" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="GlobalVars1.png" attr="" comment="" date="1319016336" name="GlobalVars1.png" path="GlobalVars1.png" size="164640" stream="GlobalVars1.png" tmpFilename="/var/tmp/CGItemp46540" user="MarjoleinVanDerWaal" version="1"
 
META TOPICMOVED by="MarjoleinVanDerWaal" date="1317049480" from="BrainStream.DocsSectionsBSArchitecture" to="BrainStream.DocsSectionsImportantConcepts"

Revision 1818 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 10 to 10
 

Markers

Changed:
<
<
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control both the insertion of markers and the actions associated with them.
>
>
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control both the insertion of markers and the actions associated with them.
  Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.
Line: 22 to 22
 

Events

Changed:
<
<
Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded objects with actions, data (optional), and variables. To some extent, it can be compared to the OOP (object oriented programming) concept. An event consists of the following:
>
>
Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded as objects with actions, data (optional), and variables. To some extent, it can be compared to the OOP (object oriented programming) concept. An event consists of the following:
  event
Changed:
<
<
name (=name of the marker that instantiates the event).
time points
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (functions, loading, modifying or saving variables)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection (optional)
Any marker can trigger the selection of a certain amount of data collection.
>
>
name (= name of the marker that instantiates the event)
time points
EVENT
DATA
time delay in seconds
another marker
For marker sequences, MRKSEQ and TIMEOUT can be used as timepoints
actions (loading, modifying or saving variables and executing functions)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session (see Parallel Mode).
data selection (optional)
Any marker can trigger the selection of a certain amount of data.
 
Changed:
<
<
Thus, an event is completely defined by the specification of actions at specific time points and optionally the amount of data that should come with it. Any combination of an action and a certain time point can only be defined once. In addition, for every processing step can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can potentially be executed at another Matlab session (i.e., a client).
>
>
Thus, an event is completely defined by the specification of actions at specific time points and optionally the amount of data that should come with it. Any combination of an action and a certain time point can only be defined once. In addition, for every processing step can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can potentially be executed at another Matlab session (i.e., a client).
  Event objects exist until all their associated actions have been handled. Events can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list.
Line: 73 to 72
 NumTrials? - NumCorrect?

Furthermore, functions can be incorporated in these expressions as long as the entire expression results in a single output. This output will then become the new content of the variable.

Changed:
<
<
InitInstructionFigure() 
>
>
InitInstructionFigure()
This example function initializes properties for a figure. The return value of this function is the handle to this figure. The figure handle may be retrieved later by means of a get operation.
 
Changed:
<
<
This example function initializes properties for a figure. The return value of this function is the handle to this figure. The figure handle may be retrieved later by means of a get operation.

Note: variables can also be of type structure. In this case a function is required to initialize the fields of the structure.
>
>

Note: variables can also be of type structure. In this case a function is required to initialize the fields of the structure.
 
<---End1--->

Revision 1710 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 37 to 37
 

Actions associated with an event

During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The Actions table specifies which actions should be executed for each event.
Changed:
<
<
Actions will be executed one by one. Actions are executed in the following order:
  1. modifying variables
  2. retrieving variable content (get, load)
  3. executing functions
  4. storing new variable content (put, save)
>
>
BrainSream always executes actions in a fixed order, based on their position in the table and the type of action. Click here for more information on the order of action execution.
 
Deleted:
<
<
If multiple functions are specified for the same time point, the functions are executed in the order in which they appear in the Actions table. Earlier functions may enrich the event with new fields or update existing values in the fields, before passing the event to the next function.
 

Revision 1610 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Added:
>
>
Generate current PDF
 

Revision 1510 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 56 to 56
 

Getting and storing content of variables

Changed:
<
<
The statements 'get' and 'put' in the Actions table control the exchange of variable content between the global variables and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the global variables into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the global variables.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
>
>
The statements 'get' and 'put' in the Actions table control the exchange of variable content between the global variables and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the global variables into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the global variables.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
  As all these actions take time, it is advisable to perform them only when needed (for example, do not copy variables into the event structure that are not used during the current event).

Revision 1405 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Line: 14 to 14
  There are different marker types, for example stimulus, response and device control markers. Marker name, number, and type combinations are stored in Dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
Changed:
<
<
When a marker is received by the platform it becomes an event.
>
>
When a marker is received by the platform it instatiates a new event.
 
Line: 23 to 23
 Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded objects with actions, data (optional), and variables. To some extent, it can be compared to the OOP (object oriented programming) concept. An event consists of the following:

event

Changed:
<
<
name (=name of the marker that instantiates the event).
time points
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (functions, loading, modifying or saving variables)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection (optional)
Any marker can trigger the selection of a certain amount of data collection.
>
>
name (=name of the marker that instantiates the event).
time points
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (functions, loading, modifying or saving variables)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection (optional)
Any marker can trigger the selection of a certain amount of data collection.
  Thus, an event is completely defined by the specification of actions at specific time points and optionally the amount of data that should come with it. Any combination of an action and a certain time point can only be defined once. In addition, for every processing step can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can potentially be executed at another Matlab session (i.e., a client).

Revision 1304 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and Global Variables

Revision 1204 Oct 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->
Changed:
<
<

Important concepts: Markers, Events and the User State

>
>

Important concepts: Markers, Events and Global Variables

 
Line: 52 to 52
 

Global variables (user state)

Changed:
<
<
Within a processing pipeline (i.e. within a single event), information between different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables, also called the user state. Users can choose any name they want for their variables, except the set of reserved variable names that are already used by BrainStream. The actions of getting the content of variables from the user state or updating modified variable content to the user state must be explicitly defined in the experiment definition tables. Variables are then copied from the user state into the event structure, so that the variables are only accessible for the duration of the event.
>
>
Within a processing pipeline (i.e. within a single event), information between different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables, also called the user state. Users can choose any name they want for their variables, except the set of reserved variable names that are already used by BrainStream. The actions of getting the content of variables from the global variables or updating modified variable content to the global variables must be explicitly defined in the experiment definition tables. Variables are then copied from the global variables into the event structure, so that the variables are only accessible for the duration of the event.
 

Getting and storing content of variables

Changed:
<
<
The statements 'get' and 'put' in the Actions table control the exchange of variable content between the user state and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the user state into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the user state.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
>
>
The statements 'get' and 'put' in the Actions table control the exchange of variable content between the global variables and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the global variables into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the global variables.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
  As all these actions take time, it is advisable to perform them only when needed (for example, do not copy variables into the event structure that are not used during the current event).

Revision 1130 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and the User State

Line: 29 to 29
  Event objects exist until all their associated actions have been handled. Events can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list.
Added:
>
>
For a more detailed description of the event structure, see Fields of the Event Structure.
 

Actions associated with an event

During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The Actions table specifies which actions should be executed for each event.

Revision 1030 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and the User State

Line: 12 to 12
  Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.
Changed:
<
<
There are different marker types, for example stimulus, response and device control markers. Marker name, number, and type combinations are stored in dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
>
>
There are different marker types, for example stimulus, response and device control markers. Marker name, number, and type combinations are stored in Dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
  When a marker is received by the platform it becomes an event.
Line: 31 to 31
 

Actions associated with an event

Changed:
<
<
During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The experiment definition tables specify for each event which actions should be executed.
>
>
During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The Actions table specifies which actions should be executed for each event.
  Actions will be executed one by one. Actions are executed in the following order:
  1. modifying variables

Revision 930 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and the User State

Line: 23 to 23
 Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded objects with actions, data (optional), and variables. To some extent, it can be compared to the OOP (object oriented programming) concept. An event consists of the following:

event

Changed:
<
<
name (=name of the marker that instantiates the event).
time points (logical time relative to the time of marker arrival, data becoming available, of another marker)
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (functions, loading, modifying or saving variables)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection (optional)
Any marker can trigger the selection of a certain amount of data collection.
>
>
name (=name of the marker that instantiates the event).
time points
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (functions, loading, modifying or saving variables)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection (optional)
Any marker can trigger the selection of a certain amount of data collection.
  Thus, an event is completely defined by the specification of actions at specific time points and optionally the amount of data that should come with it. Any combination of an action and a certain time point can only be defined once. In addition, for every processing step can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can potentially be executed at another Matlab session (i.e., a client).
Line: 80 to 80
 
<---End1--->
Added:
>
>
<-- 
  • Access control
    • Set DENYTOPICVIEW =
-->
 
META FILEATTACHMENT attachment="Slide_processing_step_2.png" attr="" comment="" date="1316783852" name="Slide_processing_step_2.png" path="Slide_processing_step_2.png" size="13938" stream="Slide_processing_step_2.png" tmpFilename="/var/tmp/CGItemp43976" user="MarjoleinVanDerWaal" version="3"
META FILEATTACHMENT attachment="Slide_processing_pipeline_2.png" attr="" comment="" date="1316783771" name="Slide_processing_pipeline_2.png" path="Slide_processing_pipeline_2.png" size="32493" stream="Slide_processing_pipeline_2.png" tmpFilename="/var/tmp/CGItemp44045" user="MarjoleinVanDerWaal" version="2"
META FILEATTACHMENT attachment="Slide_table_2.png" attr="" comment="" date="1316782771" name="Slide_table_2.png" path="Slide_table_2.png" size="35468" stream="Slide_table_2.png" tmpFilename="/var/tmp/CGItemp43991" user="MarjoleinVanDerWaal" version="1"

Revision 828 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
<---Start1--->

Important concepts: Markers, Events and the User State

Line: 10 to 10
  All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control both the insertion of markers and the actions associated with them.
Changed:
<
<
Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names? that are already used by BrainStream.
>
>
Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names that are already used by BrainStream.
  There are different marker types, for example stimulus, response and device control markers. Marker name, number, and type combinations are stored in dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
Line: 50 to 50
 

Global variables (user state)

Changed:
<
<
Within a processing pipeline (i.e. within a single event), information between different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables, also called the user state. Users can choose any name they want for their variables, except the set of reserved variable names? that are already used by BrainStream. The actions of getting the content of variables from the user state or updating modified variable content to the user state must be explicitly defined in the experiment definition tables. Variables are then copied from the user state into the event structure, so that the variables are only accessible for the duration of the event.
>
>
Within a processing pipeline (i.e. within a single event), information between different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables, also called the user state. Users can choose any name they want for their variables, except the set of reserved variable names that are already used by BrainStream. The actions of getting the content of variables from the user state or updating modified variable content to the user state must be explicitly defined in the experiment definition tables. Variables are then copied from the user state into the event structure, so that the variables are only accessible for the duration of the event.
 

Getting and storing content of variables

Revision 728 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
Added:
>
>
<---Start1--->
 

Important concepts: Markers, Events and the User State

Line: 77 to 78
  This example function initializes properties for a figure. The return value of this function is the handle to this figure. The figure handle may be retrieved later by means of a get operation.

Note: variables can also be of type structure. In this case a function is required to initialize the fields of the structure.
Added:
>
>
<---End1--->
 
META FILEATTACHMENT attachment="Slide_processing_step_2.png" attr="" comment="" date="1316783852" name="Slide_processing_step_2.png" path="Slide_processing_step_2.png" size="13938" stream="Slide_processing_step_2.png" tmpFilename="/var/tmp/CGItemp43976" user="MarjoleinVanDerWaal" version="3"
META FILEATTACHMENT attachment="Slide_processing_pipeline_2.png" attr="" comment="" date="1316783771" name="Slide_processing_pipeline_2.png" path="Slide_processing_pipeline_2.png" size="32493" stream="Slide_processing_pipeline_2.png" tmpFilename="/var/tmp/CGItemp44045" user="MarjoleinVanDerWaal" version="2"
META FILEATTACHMENT attachment="Slide_table_2.png" attr="" comment="" date="1316782771" name="Slide_table_2.png" path="Slide_table_2.png" size="35468" stream="Slide_table_2.png" tmpFilename="/var/tmp/CGItemp43991" user="MarjoleinVanDerWaal" version="1"

Revision 627 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"

Important concepts: Markers, Events and the User State

Revision 526 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"
Changed:
<
<

Architecture

>
>

Important concepts: Markers, Events and the User State

 

Markers

Line: 31 to 33
  During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The experiment definition tables specify for each event which actions should be executed.

Actions will be executed one by one. Actions are executed in the following order:

Changed:
<
<
  1. modifying variables
  2. retrieving variable content (get, load)
>
>
  1. modifying variables
  2. retrieving variable content (get, load)
 
  1. executing functions
Changed:
<
<
  1. storing new variable content (put, save)
>
>
  1. storing new variable content (put, save)
  If multiple functions are specified for the same time point, the functions are executed in the order in which they appear in the Actions table. Earlier functions may enrich the event with new fields or update existing values in the fields, before passing the event to the next function.

Changed:
<
<

Data specified for an event

>
>

Data associated with an event

 Each marker may specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a DataSelection table.
The selected data can be found in the event field event.data.raw.

Line: 80 to 82
 
META FILEATTACHMENT attachment="Slide_table_2.png" attr="" comment="" date="1316782771" name="Slide_table_2.png" path="Slide_table_2.png" size="35468" stream="Slide_table_2.png" tmpFilename="/var/tmp/CGItemp43991" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Slide_block_2.png" attr="" comment="" date="1316783090" name="Slide_block_2.png" path="Slide_block_2.png" size="37624" stream="Slide_block_2.png" tmpFilename="/var/tmp/CGItemp43913" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Slide_experiment_2.png" attr="" comment="" date="1316783558" name="Slide_experiment_2.png" path="Slide_experiment_2.png" size="62491" stream="Slide_experiment_2.png" tmpFilename="/var/tmp/CGItemp43909" user="MarjoleinVanDerWaal" version="1"
Changed:
<
<
META TOPICMOVED by="MarjoleinVanDerWaal" date="1316785315" from="BrainStream.DocsSectionBSArchitecture" to="BrainStream.DocsSectionsBSArchitecture"
>
>
META TOPICMOVED by="MarjoleinVanDerWaal" date="1317049480" from="BrainStream.DocsSectionsBSArchitecture" to="BrainStream.DocsSectionsImportantConcepts"

Revision 426 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"

Architecture

Line: 41 to 41
 

Data specified for an event

Added:
>
>
Each marker may specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a DataSelection table.
The selected data can be found in the event field event.data.raw.
 
Changed:
<
<
Each marker may specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a DataSelection table.
>
>
 
Changed:
<
<
The selected data can be found in the event field event.data.raw.
>
>

Global variables (user state)

 
Changed:
<
<
>
>
Within a processing pipeline (i.e. within a single event), information between different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables, also called the user state. Users can choose any name they want for their variables, except the set of reserved variable names? that are already used by BrainStream. The actions of getting the content of variables from the user state or updating modified variable content to the user state must be explicitly defined in the experiment definition tables. Variables are then copied from the user state into the event structure, so that the variables are only accessible for the duration of the event.

Getting and storing content of variables

The statements 'get' and 'put' in the Actions table control the exchange of variable content between the user state and the current event. These statements can be used for exchange of information between different events within the same block.

get: copy content of a variable from the user state into the event structure. The content will be copied into a new field of the event structure with the name of the variable. For example, a get statement for variable Var1 will create the field event.Var1.
put: copy the (modified) content of a variable from the event structure into the user state.

The statements 'load' and 'save' in the Actions table control the exchange of variable content between a location on disk and the current event. These statements can be used for exchange of information between different blocks.

load: load variable content from the session folder into a new field of the event structure with the name of the variable. For example, a variable stored in the session folder with the name Var1.mat will create the field event.Var1. It may often be useful to execute all load actions at the BS_INIT marker, as this will make sure that the variables are loaded at the very beginning of the block.
save: save the content of a variable to the session folder and runfolder. If 'save' is executed multiple times for a specific variable during the same block, backup copies will be saved in the runfolder while the session folder only stores the last updated value. It may often be useful to execute all save actions at the BS_EXIT marker.
 
Changed:
<
<

Variables

Global variables (user state)

>
>
As all these actions take time, it is advisable to perform them only when needed (for example, do not copy variables into the event structure that are not used during the current event).
 
Changed:
<
<
Within a processing pipeline, information between possible different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables. This communication must be explicitly defined in the experiment definition tables. The variables are copied in and out of the event structure, so that the variables are only accessible for the duration of the event. The variable names are given as headers in the action table. These variables may be copied into an event field of the same name ( ‘get’ from user state; ‘load’ from disk) updated to another value (a matlab expression, possibly containing other variable names or its own name, or $self as abbreviation of the variable itself), or vice versa copy back the value from the corresponding field in the event ( ‘put’ to user state; ‘save’ to disk). With 'save', information of some user variable is copied to the runfolder and session folder (click here for more information). If during the execution of one block 'save' is executed multiple times for a specific variable (make sure save actions do not interfer with the timing of your experiment design), backup copies will be saved in the runfolder. The session folder only stores the last updated value. Load and save are especially useful if information from one block needs to be transferred to another. A subsequent block just defines a load for the specific variable at the BS_INIT marker to get content from a previously executed block.
>
>
 

Modifying variables

Added:
>
>
Variables’ content can be modified by changing them during execution of functions, or by specifying expressions in the Actions table. Possible expressions are listed below.

Specifying only a number or string means the variable will be set to that value:
 
Changed:
<
<
Variables’ content can be modified in different ways. By changing them during execution of functions, or by specifying expressions in the table. Such expression can be simple such as ‘add one to the current value’, like $self+1, or using the name of the variable itself, like ToneCount+1, or just set it to some value. Specifying a number or string alone, means the variable will be set to that value. Expressions can use other global variables too, for instance in a Boolean expression using two of your global variables: Answer==CorrectAnswer. Furthermore, functions can be incorporated in these expressions as long as the entire expression results in a single output. This output will then become the new content of the variable. Note that also the arguments of these functions can use other global variables too, but will get parsed the values stored in the global variables space just at the time the mod-action for this processing step is started.
>
>
-1, 0, [], {} 
‘a string’
 
Changed:
<
<
Examples are:
  • Set variable to content specified:
    -1, 0, [], {}
    ‘ a string’
  • Modify content by a simple expression
     $self+1
     Answer == CorrectAnswer 
     NumTrials - NumCorrect
  • Modify content using a function
    InitInstructionFigure()
    This function initializes properties for a figure. The return value of this function is the handle to this figure and put into InstructFig. By a get operation on this variable, the application receives the handle to the figure to be used for showing instructions to the subject.
>
>
Change the current value of a variable, where $self can be used as an abbreviation for a variable's own name. :
ToneCount+1
$self+1
 
Changed:
<
<
Note: variables can also be of type structure. In this case a function is required to initialize the fields of the structure.
>
>
Expressions can use other global variables too, for instance in a Boolean expression using two of your global variables
Answer == CorrectAnswer 
NumTrials - NumCorrect
 
Changed:
<
<

Getting variable content

BrainStream maintains a central storage space (user state) for all user-defined global variables. From this space, content is being copied to the event structure (get) and vice versa updated to it (put). Users should be aware of these copying operations and prevent storage of large amounts of unused data.
>
>
Furthermore, functions can be incorporated in these expressions as long as the entire expression results in a single output. This output will then become the new content of the variable.
InitInstructionFigure() 
 
Changed:
<
<

Updating variable content

Users can choose the moments when changes made to the variables need to be updated to BrainStream’s central storage space. They should explicitly request for this by specification of a put -action at proper processing step or time point in the experiment definition table.
>
>
This example function initializes properties for a figure. The return value of this function is the handle to this figure. The figure handle may be retrieved later by means of a get operation.

Note: variables can also be of type structure. In this case a function is required to initialize the fields of the structure.
 
META FILEATTACHMENT attachment="Slide_processing_step_2.png" attr="" comment="" date="1316783852" name="Slide_processing_step_2.png" path="Slide_processing_step_2.png" size="13938" stream="Slide_processing_step_2.png" tmpFilename="/var/tmp/CGItemp43976" user="MarjoleinVanDerWaal" version="3"
META FILEATTACHMENT attachment="Slide_processing_pipeline_2.png" attr="" comment="" date="1316783771" name="Slide_processing_pipeline_2.png" path="Slide_processing_pipeline_2.png" size="32493" stream="Slide_processing_pipeline_2.png" tmpFilename="/var/tmp/CGItemp44045" user="MarjoleinVanDerWaal" version="2"

Revision 326 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"

Architecture

Line: 17 to 17
 

Events

Changed:
<
<
Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded objects with actions, data (optional), and variables.

Actions associated with an event

By definition, by markers events can execute different actions. Examples of actions are data processing (preprocessing, analyses) by means of one or a list of Matlab functions and could be a complete BCI processing chain of artifact rejects, spectral analysis, classify, output feedback. If no data is associated with the event, the action may be e.g. to display a message on the subjects screen. Actions are also getting or putting variable’s content to the global variables (user defined variables to exchange information between events), loading or saving global variable’s content from/to disk or changing its content (explained in next section). All these actions are specified in (an) experiment definition table(s).
>
>
Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded objects with actions, data (optional), and variables. To some extent, it can be compared to the OOP (object oriented programming) concept. An event consists of the following:
 
Changed:
<
<
Markers instantiate events (or event objects) that can trigger actions at various logic times after they are received; immediately (time=EVENT), after some predefined time delay (time=..s), when requested data becomes available (time= DATA), or even wait until another marker appears in the input (time=marker). Event objects are kept 'alive' until all their actions for the different time points have been handled. Also, they can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list. Conceptually a processing time is atomic: its processing is dealt with before new actions may be triggered on that marker. Reserved marker names serve to process actions at experiment startup (BS_INIT), at exit finalizing the experiment (BS_EXIT), and to quit (BS_QUIT). BrainStream will insert the BS_INIT marker at startup and the BS_EXIT marker at shutdown. Pressing the quit button from BrainStreams graphical user interface will insert a BS_QUIT marker for which the user can define an alternative exiting route. Users can connect actions to these markers in order to define whatever is needed at startup, shutdown or quitting. Multiple time-action specs may be listed below each other one per row without duplicating the marker name. This is syntactic sugar that makes the table look better, in Table 2 (for overview), color bands group actions for a specific marker. Same-time rows for the same marker will be executed in row-order. In fact this is the same as listing a sequence of actions separated by commas. Functions in the table will be passed the event, but they may have extra arguments, all passed as optional parameters. Actions may enrich the event with new fields or update existing values in the fields, before it is passed to the next action.
>
>
event
name (=name of the marker that instantiates the event).
time points (logical time relative to the time of marker arrival, data becoming available, of another marker)
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (functions, loading, modifying or saving variables)
Note - for multiple actions defined at the same time point, the processing order is determined by the type of action and the order in which actions appear in the Actions table.

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection (optional)
Any marker can trigger the selection of a certain amount of data collection.
 
Changed:
<
<
Time can be one of the following:
EVENT
DATA
a number
another mrk
MRKSEQ
TIMEOUT
>
>
Thus, an event is completely defined by the specification of actions at specific time points and optionally the amount of data that should come with it. Any combination of an action and a certain time point can only be defined once. In addition, for every processing step can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can potentially be executed at another Matlab session (i.e., a client).
 
Changed:
<
<
Executed at marker onset
Executed as data becomes available
Executed number seconds after marker onset
Executed at onset of marker mrk
only for marker sequences
only for marker sequences
>
>
Event objects exist until all their associated actions have been handled. Events can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list.
 
Changed:
<
<
To completely understand the rich structure of an event, it is important to realize that it is an ‘object’ with data and functionality. To some extent, it can be compared to the OOP (object oriented programming) concept. An object in OOP has data and functionality attached to it. The data can be partially public, and partially private. The functions operate on the data of the object, and can take additional data as input argument (e.g., put (new_value)). Differences to this OOP concept are 1) not all functionality is included, i.e., for functions the event object only refers to Matlab functions and doesn’t actually include its code, although for simple variable modifications, Matlab inline functions are included within the object; 2) during the execution of an event, new variables can be added, but will only exist during the ‘lifetime’ of the event; 3) it contains a predefined time scheme of when what actions should be executed, i.e., its ‘lifetime’ is known at forehand (it will be destroyed as soon as all actions have been executed).

An event consists of the following:
>
>

Actions associated with an event

During an event, different actions can be executed at various times after the onset of the event. Actions may consist of the execution of user defined functions, or may involve loading, modifying or saving variables. The experiment definition tables specify for each event which actions should be executed.
 
Changed:
<
<
event
name (names can be freely chosen and spaces are allowed)
time points (logical time referring to time of marker arrival, data becoming available, of another marker)
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (function(s), modify variable(s), get or load, put or save)
modify variable
get variable(s)
load variable(s)
execute function(s)
put variable(s)
save variable(s)
Note - for multiple actions defined at equal time points, the processing order is determined by the type of action and as depicted in former list

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection
Any table can include a separate DataSelection? ? sheet to define possible requested data for any marker, also in a very flexible way (see next paragraph).
>
>
Actions will be executed one by one. Actions are executed in the following order:
  1. modifying variables
  2. retrieving variable content (get, load)
  3. executing functions
  4. storing new variable content (put, save)
 
Changed:
<
<
This implies that an event is completely defined by specification of the actions for the time points and what amount of data should come with it. Define tp one of the possible time points, and ac one of the possible actions. Any combination of (tp,ac) can only be defined once.
In addition, for every time point or processing step it can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can optional dedicate execution to another Matlab session, i.e., a client.
>
>
If multiple functions are specified for the same time point, the functions are executed in the order in which they appear in the Actions table. Earlier functions may enrich the event with new fields or update existing values in the fields, before passing the event to the next function.
 
Changed:
<
<
>
>
 

Data specified for an event

Deleted:
<
<
Each marker can optional specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a data selection table, like the table in the figure below.

  • slide_dataselection.gif
 
Changed:
<
<
Positive numbers mean after, negative mean before onset of the marker. Events associated with marker mrk1 will receive data from 0.2 second before its arrival to 1.0 second after. Marker mrk2 receives all its data from a period before its arrival. Another marker may also terminate data reception. Marker A shows an example of how to compose flexible sized data epochs where each new occurrence of marker A ends data collection of its own previous one. This sequence ends by the occurrence of another marker B that stops data collection for the last marker A in row. Data associated with marker C will extent till another marker D is received (marker D could for example be associated with a button press event). Both data collection for markers A and C may timeout (if marker B repectively D does not arrive) after timeout seconds, as specified by the user. Note that if ending markers do not set the end of data selection and no timeout is specified, corresponding processing steps will never execute. Mentioned times t1, t2, and t3 can all be positive or negative numbers (or zero), and specify data selection end points relative to onset of the corresponding end marker. Multiple markers can end data collection for a specific marker. For marker A the endtime could also be something like: B+t1, C+t4, D+t5 etc. Instead of specifying timing offsets in seconds, they can also be specified in number of samples. To indicate such number should be interpreted as a number instead of time, put a '#' symbol behind the number (like, 1024#). For marker mrk1 a specification in sample numbers would make the table information: mrk1 -51# 256# considering a sample rate of 256 Hz.
Note that in the first case, 0.2 seconds will also be rounded off to the nearest integer (-51) by BrainStreams internal processing.
>
>
Each marker may specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a DataSelection table.
 
Changed:
<
<
Multiple end time specification (separated by a comma) constitutes an implicit minimum. Row 4 specifies that MarkerA_'s data collection stops t2 second after receiving _MarkerB, or after timeout seconds, whatever happens first. The table can have a duration column (calculated from the start) and/or a endtime column. And the start column may be headed offset (in fieldtrip style). not yet implemented
>
>
The selected data can be found in the event field event.data.raw.
 
Changed:
<
<
Later versions of BrainStream also support using a marker as logical begintime of data selection. In that case, it is not allowed to specify a marker for the endtime also.
>
>
 

Variables

Global variables (user state)

Revision 226 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
 
META TOPICPARENT name="BrainStreamDocs"

Architecture

Added:
>
>
 

Markers

Changed:
<
<
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers. Markers are received in synchrony with the data stream (they have a sample-accurate time resolution). Markers can be inserted by means of user defined functions.
>
>
All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers, which are received in synchrony with the data stream. Markers in themselves do not represent any kind of processing. Meaning is given to them by the actions (processing steps or pipelines) associated with the markers. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints. Users can control both the insertion of markers and the actions associated with them.

Outside BrainStream, markers are represented as numbers. However, as numbers are easy to confuse, the BrainStream platform works with marker names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Users can specify any name for their markers, except the set of reserved marker names? that are already used by BrainStream.

 
Changed:
<
<
Markers in themselves do not represent any kind of processing. Meaning is given to them by the defined actions of processing steps or pipelines associated with this marker. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints.
>
>
There are different marker types, for example stimulus, response and device control markers. Marker name, number, and type combinations are stored in dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
 
Changed:
<
<
There can be different types of markers, for example stimulus, response and device control markers. As numbers are easy to confuse, the BrainStream platform works with names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Marker name, number, and type combinations are stored in dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.
>
>
When a marker is received by the platform it becomes an event.
 
Changed:
<
<
When a marker is received by the platform it becomes an event, based on definitions of corresponding processing pipeline.
>
>
 

Events

Changed:
<
<
Markers are received in synchrony with the data stream (they have a sample-accurate time resolution). They always have a specified order and translate their associated processing pipelines into events when received. Events have rich structure and can be regarded objects with data (optional), variables, and actions with different moments of execution relative to the onset of the event. Every subsequent same marker in the data stream instantiates a new event.

Actions associated with an event

>
>
Every marker in the data stream instantiates a new event. Events have a rich structure and can be regarded objects with actions, data (optional), and variables.

Actions associated with an event

  By definition, by markers events can execute different actions. Examples of actions are data processing (preprocessing, analyses) by means of one or a list of Matlab functions and could be a complete BCI processing chain of artifact rejects, spectral analysis, classify, output feedback. If no data is associated with the event, the action may be e.g. to display a message on the subjects screen. Actions are also getting or putting variable’s content to the global variables (user defined variables to exchange information between events), loading or saving global variable’s content from/to disk or changing its content (explained in next section). All these actions are specified in (an) experiment definition table(s).

Markers instantiate events (or event objects) that can trigger actions at various logic times after they are received; immediately (time=EVENT), after some predefined time delay (time=..s), when requested data becomes available (time= DATA), or even wait until another marker appears in the input (time=marker). Event objects are kept 'alive' until all their actions for the different time points have been handled. Also, they can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list. Conceptually a processing time is atomic: its processing is dealt with before new actions may be triggered on that marker. Reserved marker names serve to process actions at experiment startup (BS_INIT), at exit finalizing the experiment (BS_EXIT), and to quit (BS_QUIT). BrainStream will insert the BS_INIT marker at startup and the BS_EXIT marker at shutdown. Pressing the quit button from BrainStreams graphical user interface will insert a BS_QUIT marker for which the user can define an alternative exiting route. Users can connect actions to these markers in order to define whatever is needed at startup, shutdown or quitting. Multiple time-action specs may be listed below each other one per row without duplicating the marker name. This is syntactic sugar that makes the table look better, in Table 2 (for overview), color bands group actions for a specific marker. Same-time rows for the same marker will be executed in row-order. In fact this is the same as listing a sequence of actions separated by commas. Functions in the table will be passed the event, but they may have extra arguments, all passed as optional parameters. Actions may enrich the event with new fields or update existing values in the fields, before it is passed to the next action.

Line: 33 to 37
 
Changed:
<
<

Data specified for an event

>
>

Data specified for an event

  Each marker can optional specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a data selection table, like the table in the figure below.

  • slide_dataselection.gif

Revision 123 Sep 2011 - Main.MarjoleinVanDerWaal

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="BrainStreamDocs"

Architecture

Markers

All processing steps and pipelines need to be executed at a specific time and in a specific order. This is handled by markers. Markers are received in synchrony with the data stream (they have a sample-accurate time resolution). Markers can be inserted by means of user defined functions.

Markers in themselves do not represent any kind of processing. Meaning is given to them by the defined actions of processing steps or pipelines associated with this marker. Actions can be freely defined in order to accomplish some particular task, for example presenting stimuli to participants, numerical data processing, or controlling a data acquisition system. Incoming markers can initiate an unlimited sequence of actions at an unlimited number of timepoints.

There can be different types of markers, for example stimulus, response and device control markers. As numbers are easy to confuse, the BrainStream platform works with names everywhere. Names are strings, can contain characters (a-z), numbers (0-9), and must start with a character. Marker name, number, and type combinations are stored in dictionary tables. The set of dictionaries must be unique, i.e., for a certain marker type one cannot specify the same number multiple times, and overall marker names must be unique.

When a marker is received by the platform it becomes an event, based on definitions of corresponding processing pipeline.

Events

Markers are received in synchrony with the data stream (they have a sample-accurate time resolution). They always have a specified order and translate their associated processing pipelines into events when received. Events have rich structure and can be regarded objects with data (optional), variables, and actions with different moments of execution relative to the onset of the event. Every subsequent same marker in the data stream instantiates a new event.

Actions associated with an event

By definition, by markers events can execute different actions. Examples of actions are data processing (preprocessing, analyses) by means of one or a list of Matlab functions and could be a complete BCI processing chain of artifact rejects, spectral analysis, classify, output feedback. If no data is associated with the event, the action may be e.g. to display a message on the subjects screen. Actions are also getting or putting variable’s content to the global variables (user defined variables to exchange information between events), loading or saving global variable’s content from/to disk or changing its content (explained in next section). All these actions are specified in (an) experiment definition table(s).

Markers instantiate events (or event objects) that can trigger actions at various logic times after they are received; immediately (time=EVENT), after some predefined time delay (time=..s), when requested data becomes available (time= DATA), or even wait until another marker appears in the input (time=marker). Event objects are kept 'alive' until all their actions for the different time points have been handled. Also, they can be discarded prematurely by calling an explicit 'cancel' function from one of the user functions in the list. Conceptually a processing time is atomic: its processing is dealt with before new actions may be triggered on that marker. Reserved marker names serve to process actions at experiment startup (BS_INIT), at exit finalizing the experiment (BS_EXIT), and to quit (BS_QUIT). BrainStream will insert the BS_INIT marker at startup and the BS_EXIT marker at shutdown. Pressing the quit button from BrainStreams graphical user interface will insert a BS_QUIT marker for which the user can define an alternative exiting route. Users can connect actions to these markers in order to define whatever is needed at startup, shutdown or quitting. Multiple time-action specs may be listed below each other one per row without duplicating the marker name. This is syntactic sugar that makes the table look better, in Table 2 (for overview), color bands group actions for a specific marker. Same-time rows for the same marker will be executed in row-order. In fact this is the same as listing a sequence of actions separated by commas. Functions in the table will be passed the event, but they may have extra arguments, all passed as optional parameters. Actions may enrich the event with new fields or update existing values in the fields, before it is passed to the next action.

Time can be one of the following:

EVENT
DATA
a number
another mrk
MRKSEQ
TIMEOUT

Executed at marker onset
Executed as data becomes available
Executed number seconds after marker onset
Executed at onset of marker mrk
only for marker sequences
only for marker sequences

To completely understand the rich structure of an event, it is important to realize that it is an ‘object’ with data and functionality. To some extent, it can be compared to the OOP (object oriented programming) concept. An object in OOP has data and functionality attached to it. The data can be partially public, and partially private. The functions operate on the data of the object, and can take additional data as input argument (e.g., put (new_value)). Differences to this OOP concept are 1) not all functionality is included, i.e., for functions the event object only refers to Matlab functions and doesn’t actually include its code, although for simple variable modifications, Matlab inline functions are included within the object; 2) during the execution of an event, new variables can be added, but will only exist during the ‘lifetime’ of the event; 3) it contains a predefined time scheme of when what actions should be executed, i.e., its ‘lifetime’ is known at forehand (it will be destroyed as soon as all actions have been executed).

An event consists of the following:

event

name (names can be freely chosen and spaces are allowed)
time points (logical time referring to time of marker arrival, data becoming available, of another marker)
EVENT
DATA
time delay in seconds
another marker
MRKSEQ (only for marker sequences, see here)
TIMEOUT (only for marker sequences, see here)
actions (function(s), modify variable(s), get or load, put or save)
modify variable
get variable(s)
load variable(s)
execute function(s)
put variable(s)
save variable(s)
Note - for multiple actions defined at equal time points, the processing order is determined by the type of action and as depicted in former list

client
Option to dedicate execution of processing step (time point) to another Matlab session.
data selection
Any table can include a separate DataSelection? ? sheet to define possible requested data for any marker, also in a very flexible way (see next paragraph).

This implies that an event is completely defined by specification of the actions for the time points and what amount of data should come with it. Define tp one of the possible time points, and ac one of the possible actions. Any combination of (tp,ac) can only be defined once.
In addition, for every time point or processing step it can be specified where it should execute. Since BrainStream supports a design with multiple Matlab sessions running in parallel, every processing step can optional dedicate execution to another Matlab session, i.e., a client.

Data specified for an event

Each marker can optional specify a segment of data that should come along with the event. Data may start before or after onset of the marker and end before or after it. Data begin and end times are specified in a data selection table, like the table in the figure below.

  • slide_dataselection.gif

Positive numbers mean after, negative mean before onset of the marker. Events associated with marker mrk1 will receive data from 0.2 second before its arrival to 1.0 second after. Marker mrk2 receives all its data from a period before its arrival. Another marker may also terminate data reception. Marker A shows an example of how to compose flexible sized data epochs where each new occurrence of marker A ends data collection of its own previous one. This sequence ends by the occurrence of another marker B that stops data collection for the last marker A in row. Data associated with marker C will extent till another marker D is received (marker D could for example be associated with a button press event). Both data collection for markers A and C may timeout (if marker B repectively D does not arrive) after timeout seconds, as specified by the user. Note that if ending markers do not set the end of data selection and no timeout is specified, corresponding processing steps will never execute. Mentioned times t1, t2, and t3 can all be positive or negative numbers (or zero), and specify data selection end points relative to onset of the corresponding end marker. Multiple markers can end data collection for a specific marker. For marker A the endtime could also be something like: B+t1, C+t4, D+t5 etc. Instead of specifying timing offsets in seconds, they can also be specified in number of samples. To indicate such number should be interpreted as a number instead of time, put a '#' symbol behind the number (like, 1024#). For marker mrk1 a specification in sample numbers would make the table information: mrk1 -51# 256# considering a sample rate of 256 Hz.
Note that in the first case, 0.2 seconds will also be rounded off to the nearest integer (-51) by BrainStreams internal processing.

Multiple end time specification (separated by a comma) constitutes an implicit minimum. Row 4 specifies that MarkerA_'s data collection stops t2 second after receiving _MarkerB, or after timeout seconds, whatever happens first. The table can have a duration column (calculated from the start) and/or a endtime column. And the start column may be headed offset (in fieldtrip style). not yet implemented

Later versions of BrainStream also support using a marker as logical begintime of data selection. In that case, it is not allowed to specify a marker for the endtime also.

Variables

Global variables (user state)

Within a processing pipeline, information between possible different processing steps is preserved. However, different processing pipelines can only exchange information via a set of globally maintained variables. This communication must be explicitly defined in the experiment definition tables. The variables are copied in and out of the event structure, so that the variables are only accessible for the duration of the event. The variable names are given as headers in the action table. These variables may be copied into an event field of the same name ( ‘get’ from user state; ‘load’ from disk) updated to another value (a matlab expression, possibly containing other variable names or its own name, or $self as abbreviation of the variable itself), or vice versa copy back the value from the corresponding field in the event ( ‘put’ to user state; ‘save’ to disk). With 'save', information of some user variable is copied to the runfolder and session folder (click here for more information). If during the execution of one block 'save' is executed multiple times for a specific variable (make sure save actions do not interfer with the timing of your experiment design), backup copies will be saved in the runfolder. The session folder only stores the last updated value. Load and save are especially useful if information from one block needs to be transferred to another. A subsequent block just defines a load for the specific variable at the BS_INIT marker to get content from a previously executed block.

Modifying variables

Variables’ content can be modified in different ways. By changing them during execution of functions, or by specifying expressions in the table. Such expression can be simple such as ‘add one to the current value’, like $self+1, or using the name of the variable itself, like ToneCount+1, or just set it to some value. Specifying a number or string alone, means the variable will be set to that value. Expressions can use other global variables too, for instance in a Boolean expression using two of your global variables: Answer==CorrectAnswer. Furthermore, functions can be incorporated in these expressions as long as the entire expression results in a single output. This output will then become the new content of the variable. Note that also the arguments of these functions can use other global variables too, but will get parsed the values stored in the global variables space just at the time the mod-action for this processing step is started.

Examples are:

  • Set variable to content specified:
    -1, 0, [], {}
    ‘ a string’
  • Modify content by a simple expression
     $self+1
     Answer == CorrectAnswer 
     NumTrials - NumCorrect
  • Modify content using a function
    InitInstructionFigure()
    This function initializes properties for a figure. The return value of this function is the handle to this figure and put into InstructFig. By a get operation on this variable, the application receives the handle to the figure to be used for showing instructions to the subject.

Note: variables can also be of type structure. In this case a function is required to initialize the fields of the structure.

Getting variable content

BrainStream maintains a central storage space (user state) for all user-defined global variables. From this space, content is being copied to the event structure (get) and vice versa updated to it (put). Users should be aware of these copying operations and prevent storage of large amounts of unused data.

Updating variable content

Users can choose the moments when changes made to the variables need to be updated to BrainStream’s central storage space. They should explicitly request for this by specification of a put -action at proper processing step or time point in the experiment definition table.

META FILEATTACHMENT attachment="Slide_processing_step_2.png" attr="" comment="" date="1316783852" name="Slide_processing_step_2.png" path="Slide_processing_step_2.png" size="13938" stream="Slide_processing_step_2.png" tmpFilename="/var/tmp/CGItemp43976" user="MarjoleinVanDerWaal" version="3"
META FILEATTACHMENT attachment="Slide_processing_pipeline_2.png" attr="" comment="" date="1316783771" name="Slide_processing_pipeline_2.png" path="Slide_processing_pipeline_2.png" size="32493" stream="Slide_processing_pipeline_2.png" tmpFilename="/var/tmp/CGItemp44045" user="MarjoleinVanDerWaal" version="2"
META FILEATTACHMENT attachment="Slide_table_2.png" attr="" comment="" date="1316782771" name="Slide_table_2.png" path="Slide_table_2.png" size="35468" stream="Slide_table_2.png" tmpFilename="/var/tmp/CGItemp43991" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Slide_block_2.png" attr="" comment="" date="1316783090" name="Slide_block_2.png" path="Slide_block_2.png" size="37624" stream="Slide_block_2.png" tmpFilename="/var/tmp/CGItemp43913" user="MarjoleinVanDerWaal" version="1"
META FILEATTACHMENT attachment="Slide_experiment_2.png" attr="" comment="" date="1316783558" name="Slide_experiment_2.png" path="Slide_experiment_2.png" size="62491" stream="Slide_experiment_2.png" tmpFilename="/var/tmp/CGItemp43909" user="MarjoleinVanDerWaal" version="1"
META TOPICMOVED by="MarjoleinVanDerWaal" date="1316785315" from="BrainStream.DocsSectionBSArchitecture" to="BrainStream.DocsSectionsBSArchitecture"
 
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