Page History: Events
Compare Page Revisions
Page Revision: 2015/01/03 08:30
|
Events
|
Info |
Category: |
Design object |
Role: |
Scenario |
Properties
Generic Properties
Name | Description | Constrains | Type |
---|
Control |
Duration | efines the minimal requested duration of the event in ms. The duration is a period between the onset and offset of the event. The actual duration may depend on the conditional flow logic and the refresh rate of monitor, when the vertical synchronization is on. 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. | | Bool |
Screen Cloning | Defines whether a replica of event's surface is sent for monitoring on the Status Screen (via the Clone Screen property in HQ). Screen cloning, albeit accelerated, may decrease timing accuracy and, therefore, is not recommended for the time-critical events. | | Bool |
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. | | enum |
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. | | Bool |
Control Pace Time | 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. | | Bool |
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 |
Radar Provider | 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 ROI 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. | | enum |
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 on 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 (a trajectory) that represent the newest positional input, which is obtained in the last Control Loop cycle. The last valid screen point in this array is the same, as a value of the Radar Point property. | | clPoint[] |
Runtime Status |
Elapsed Time | Returns the time passed since the onset of the current event (ms). This property can be used as a timer for code-controlled actions within the current 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 |
Subevent Index | Indicates an index of the currently active event on the event's sublayer. The property can be used for monitoring a flow of the events on the sublayer. 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 |
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 depends 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 Interval | Returns the continuously re-measured time interval (ms) between two consecutive step of the event's Control Loop. If there are ongoing computational load or snippet calls in the experiment, the interval is about 1ms. | | clTime |
Snippets Times | Returns the statistics of executions times (in ms) for all code snippets within 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. | | Dictionary[string] |
Description
Events are timeline blocks that build up an experiment scenario in EventIDE. A typical scenario is composed of a sequence of events, which are activated one by one, in the order defined by flow logic. Events are often associated with displays containing some graphics content, like slides in Microsoft PowerPoint. However, events can carry non-visual logic as well- for example, an event can be created that sends data via a serial port, while keeping the visual scene unchanged.
Event Layers
Events are organized in the event layers which can contain any number of events. At runtime, only one event can be active in time on the event layer. Thus, events in the event layer are activated one by one according to the predefined event flow, which can be controlled either by timing or/and logical conditions. 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.
Content of events
The functional role of the event is often defined by
elements that belong to event's own element list. Each event works as a container where you put multiple elements of different types. After adding an element you can set and adjust element's properties. For example, if you add the Text Element into an event and set element's property Text to "Hello, World!" then, when you run an experiment and get the event activated, you will see this global greeting on your screen.
Event as a working scope
Event also represents a working scope for its elements. For example, you can add the Button element into an Event, which becomes a parent event for the created element. The button element will be able to detect a pressing of the particular button only while the parent Event is active. As soon as the experiment flow switches to another event all button presses will be ignored.
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.
Snapshots
Snapshot 1
| Snapshot 2 |
Practical Use
Once you create a new blank experiment, it contains a root event layer with a single event. You can add new events via the Event ribbon tab. New events appear in the Event panel, where you can reorder them by dragging. To manage event
layers press the right-most button in the event panel.
Figure 1: Hovering with the mouse on the gray border of an existing event means that a plus icon will appear and a new event can be added.Three relevant event windows are depicted in the first view below: Event Representation (panel), Event, description (the central one) and Event's elements (the left central panel) (Figure 2).
Figure 2: First screen presented to the user when you open a new experiment in EventIDE.The Event representation window allows control over an event by determining whether the event is activated by time or by a particular condition (the clock/pen icon on the bottom left) and how many milliseconds the event will be active for (the number (ms) in the center).
Activating an event by time (the clock icon) means that it will automatically be activated when the previous event in the sequence (as defined by the
Event Flow Chart) is completed.
Activating an event by condition (the pen icon) means that the event will only be activated upon the resolution of a logical condition, the code for which can be inserted in the code snippets section at the bottom of the window (in box
Condition). For example feedback might be given to a participant at the end of each trial, in which case the event will be activated upon a button press.
Activating an event by either condition or time (the half pen/half clock icon with the orange line) means that either a condition has to be met, or a previous event has to have lapsed before the event is activated. For example feedback might be given to a participant at the end of each trial – this may be conditional upon a button press, or after the stimuli has been shown for a certain period of time (such as 5000 ms).
Activating an event by both condition and time (half pen/half clock icon) means that a logical condition (as defined in the
Condition code snippets) and a time condition have to be met before activation of the event (Figure 3)
Figure 3: Icons representing conditions to move to the next event.