|
Event
|
| Info |
| Category: |
Design object |
| Role: |
Procedure design |
Properties
| Name | Description | Constraints | Type | On
runtime
change |
|---|
| Control |
| Title | Defines the event title, as it appears in GUI | | String | |
| Duration | Defines the minimal duration of the event in ms. The duration is a period between event's onset and offset. The actual duration may depend on the conditional flow logic and monitor's refresh rate for visual events. The predicted actual duration is shown to the right of the value. | | clTime | |
| Show Mouse Cursor | Defines whether the system mouse cursor is shown, while the event is active. Note that the property can be overridden by a subevent. The mouse cursor can not be shown, if the Exclusive Input in HQ is on. | | Boolean | |
| Screen Cloning | Defines whether a replica of event's surface is sent for monitoring on the Status Screen (via the Clone Screen property in the Experiment ribbon tab). Screen cloning, albeit accelerated, may decrease timing accuracy and, therefore, is not recommended for the time-critical events. | | Boolean | |
| Rendering Snippet | Defines when the event's rendering snippet is invoked during the course of the rendering pipeline. Note that the rendering snippet in never invoked for non-visual events, even if the snippet contains code. | | Int32 | |
| Live Rendering | Defines whether any change on the event surface causes an immediate visual update, given that the event is on-screen. If false, the update will be done off-screen only, such that the new visual content will be presented only on the next event onset. | | Boolean | |
| Control Loop Pace | Defines the minimal time interval (ms) between two consequent calls of the control loop snippet of this event. The default value, 0, means that the snippet is called as frequently, as possible. The property does not affects the pace of the inner control loop for the elements. | | Double | |
| Is Time Critical | Defines whether the timing in this event is critical. Note if sub-events exists in this event, each of them overrides this property | | Boolean | |
| Visual Appearance |
| Background Color | Defines the background color of the event surface. The default background is transparent, which allows to compose visual items of the current event with the visual surface of the parent event. | | stColor | |
| Rotation | Defines the angle of a global rotational transform, which is applied to the event surface and all visual items. The value is set in degrees, in 0..360 range, and goes anti-clock wise starting from the right tail of a horizontal axis that crosses the screen center. | | Double | |
| Positional Shift | Defines a global positional transform, which applied to to the event surface and all visual items, separately for the X and Y axis. The default value is (0,0) which means no shift applied. | | clPoint | |
| Scale | Defines a global scaling transform, which applied to to the event surface and all visual items, separately for the X and Y axis, relatively to the screen center. The default value is (1,1) which means no transformation. The values less than 1 produce the downscaling, and values greater than 1 results in the upscaling. The negative values, e.g. -1, flip the surface over the corresponding axis. | | clScale | |
| Positional Input |
| Tracking Device | Defines which of the radar providers is used for positional input in this event. In each experiment, the radar providers includes the system mouse and all tracker elements. The selected radar provider controls the Radar Point property and input to the AOI elements in this event. When 'Auto' is chosen, the first tracker element is picked up. If there are no tracker elements, the system mouse is used by default. | | String | |
| Radar Point | Returns the newest screen position obtained via the selected Radar provider, e.g. the mouse or eye-tracker. The property value is updated every Control Loop cycle in the event. When the position is provided by the system mouse, you can write the property in order to move the mouse cursor. Otherwise, the Radar property is read-only and writings are ignored. | | clPoint | |
| Radar Buffer | Returns an array of screen coordinates representing the most recent current positional input arrived in the last Control Loop interval. The last valid screen point in the array is the same as a value of the Radar point property. | | clPoin.. | |
| Runtime Status |
| Elapsed Time | The time passed since the onset of the given event (ms). This property can be used as a timer for code-controlled actions within the given event. | | clTime | |
| Frame Duration | Returns the actual frame duration in live rendering. The live rendering is performed, when the on-screen event redraws its surface in response a visual change. For example, the live rendering occurs, when video is presented or visual animation is programmed in snippets. The duration is refreshed on every screen update. | | clTime | |
| Preceding Event | Returns a name of the immediately preceding event on the same layer during a run. | | String | |
| Subevent Index | Returns an index of the currently active event on event's sublayer. The property can be used for monitoring the subevent flow. The property also allows to control the subevent flow manually, bypassing the flow routes: when a new event index is assigned to the property in snippets, the corresponding event will be immediately activated on the sublayer. | | Int32 | |
| Timing Statistics |
| Measured Duration | Returns the actual duration of the event measured after the event offset. You can check or record this property in order to validate the expected timing accuracy of the experiment. | | clTime | |
| Onset Time | Returns the actual time of the last onset of this event in ms. passed since the start of the experiment. | | clTime | |
| Composition Time | Returns the time (ms) that the given event spends for composing its visual surface in the off-screen buffer. The composition is the first part of the event rendering pipeline and the time depend on a number of the visual elements. | | clTime | |
| Rendering Time | Returns the time (ms) that the given event spends for rendering its off-screen buffer onto the screen. The rendering is the last part of the event rendering pipeline and the time does not depend on a number of the visual elements. | | clTime | |
| Control Loop Delta | Returns continuously re-measured time delta (ms) between two consecutive step of the event's control loop. If there are no going computational load or snippet calls in the experiment the interval is below 1ms. | | clTime | |
| Snippet Call Times | Returns the statistics of executions times (in ms) for the code snippets in a scope of the given event. Statistics of a single snippet can be accessed by snippet's name, e.g.: 'clTime Time=(clTime) SnippetTimes'After Onset';' The snippet mush contain code to be included into the list. | | Dictio.. | |
|
Description
Events are timeline blocks that build up an experiment scenario in EventIDE. A simple scenario is composed of a sequence of events, which are activated one by one, in the order defined by a custom flow logic. The events are often associated with displays containing some graphics content, like slides in PowerPoint. However, the events can carry non-visual logic as well- for example, an event can be created that sends data via a computer port, while keeping the visual display unchanged.
Event Layers
Events are organized in the event layers, which can contain any number of events. Only one event can be active on the event layer at runtime. The order of the events in the event layer is controlled either by timing or/and logical conditions, defined by
flow routes. Multiple event layers can be presented in an experiment, arranged in a hierarchical fashion.
Order of events
Presentation of events always starts with the first event on the event layer. Then, the presentation order is defined by
flow routes that you create in accordance with the experiment logic. When there are no outgoing flow routes defined, the current event stays active. A single event can be reactivated many times, if a flow logic demands it.
Event as a container and working scope ¶
What happens within the event is defined either by
attached code, or by
elements that can be added to event's element list. Each event is a container, in which you can put elements with different functions. For example, if you add the
Text Element into an event and run the experiment, you will see a text on the onset of the event. The text will disappear on the event offset.
If you add the
Button Element, it will register button presses, while the event is active. Thus, the event also represents a working scope for its elements.
In certain scenarios, you may want to be able to detect a button press during several consecutive events that, for example, provide a transformation of the visual stimulus. To solve it, you can create several button elements for each of the visual events but there is an easier solution: any Event can be expanded with its own layer of children events (event sublayer). For the discussed button scenario you should simply: 1) select a single parent event, 2) add an event sublayer on it, 3) create on the sublayer several children events that are responsible for stimulus transformation and, 4) add a Button element into the Parent event. After doing it, a button press will be detected anytime while a stimulus transformation is performed. The hierarchy of events and events layers in EventIDE offers a very powerful and flexible tool for creating custom experiment scenarios. Events represent main building blocks for any experiment scenario in EventIDE. A typical scenario consists of a sequence of events which are activated one by one, according to a logic predefined by the event flow. In the simplest case, events can be associated with visual scenes containing their own graphics content, like slides in Microsoft PowerPoint. Then, the whole experiment will appear as a sequence of visual scenes. However, events can be tied to the non-visual actions as well- for example, with initiation a serial port communication at the certain time, while keeping visual output on the screen unchanged.
Practical Use
Creating a new event
Once you create a new experiment, it contains one event layer with a single event. You can add new events via the button left to the event panel:
 Adding events via the event panel |
New event will appear in the Event panel, in the last position. Then you can reorder the event by dragging. If you want to manage the event layers or flow routes, press the large button to the right of the event panel.
Removing the events
If you want to remove one or more event, select them in the element panel (keep Shift or Ctrl pressed for multi-selection) and press Del button. You can also open a context menu with all comands by the right mouse click.
Editing the event title and duration ¶
Using the event panel, you can edit the event title and duration. Move the mouse over the title or duration in the event box (see below) and make a double click to activate the editing mode. Then, type a new value.
 Editing the event title in the event panel |