LabBench CPAR+

Mon, 01 Jan 0001 00:00:00 +0000

The LabBench CPAR+ is a computer-controlled cuff pressure algometer that delivers precise, reproducible pressure stimulation for neuroscience research. It generates customisable piecewise-linear pressure waveforms with accurate temporal control, supporting advanced psychophysical protocols. The device enables automated cuff pressure algometry protocols that are not feasible with manual devices.

The LabBench CPAR+ device is included in experimental setups with an <cparplus> element:

<cpar-plus id="cpar"
            button="joystick"
            rating-scale="display.vas" />

Attributes:

Name Use Description

required

Temporal Summation

Mon, 01 Jan 0001 00:00:00 +0000

The temporal summation procedure applies a series of rectangular pressure stimuli to one or both cuffs. The participant is asked to rate the pain sensation of these stimuli on the VAS meter as soon as possible after the cessation of a pressure stimulus. The VAS rating for a stimulus is recorded just before the next stimulus is given or would have been given if it had not been the last stimulus in the series.

Arbitrary Temporal Summation

Mon, 01 Jan 0001 00:00:00 +0000

The arbitrary temporal summation procedure applies a series of rectangular pressure stimuli to one or both cuffs.

The participant is asked to rate the pain sensation of these stimuli on the VAS meter as soon as possible after the cessation of a pressure stimulus.

The VAS rating for a stimulus is recorded just before the next stimulus is given or would have been given if it had not been the last stimulus in the series. The arbitrary temporal summation procedure makes it possible to specify each stimulus in the series individually, and thus, each stimulus can have a different intensity and duration.

Static Temporal Summation

Mon, 01 Jan 0001 00:00:00 +0000

The static temporal summation applies a constant pressure for a specified duration instead of a series of stimuli to determine the temporal summation of pressure stimulation.

During this pressure stimulation and for a period after the procedure, the participant’s VAS score will be recorded as the result of the procedure.

The procedure window for the <algometry-static-temporal-summation> procedure is shown in Figure 1. The procedure window consists of two areas: applied pressure and recorded responses.

Conditioned Pain Modulation

Mon, 01 Jan 0001 00:00:00 +0000

With the conditioned pain modulation procedure, one cuff applies static pressure while the other determines a stimulus-response curve. The stimulus-response curve determines the psychophysical rating (VAS Rating) to a linearly increasing pressure stimulus.

From this stimulus-response curve, several psychophysical parameters can be determined:

Pain Detection Threshold (PDT),
Pain Tolerance Limit (PTL),
Pain Tolerance Threshold (PTT).

The determined parameters depend on the procedure configuration and the participant’s instructions.

The procedure window for the <algometry-conditioned-pain-modulation> procedure is shown in Figure 1. The procedure window consists of two areas: applied pressure and recorded responses.

LabBench SERVER

Mon, 01 Jan 0001 00:00:00 +0000

LabBench Device Server

The <server> device lets LabBench use a Device Server tactor through the normal IStimulator instrument contract. The first supported sub-instrument is tactor, so device mappings should refer to the sub-instrument ID as [server device id].tactor.

The setup contains exactly one <tactor> element. Its id defaults to tactor; keep that value unless the experiment needs another sub-instrument name. The tactor must contain one LabBench stimulator setup so LabBench knows the tactor modality, unit, and intensity range.

LabBench SOUND

Mon, 01 Jan 0001 00:00:00 +0000

Soundcards in LabBench enable precise generation of audio signals, making them suitable for a wide range of auditory, psychophysical, and neurophysiological experiments. By leveraging low-latency playback, multi-channel audio, and tight synchronisation with other LabBench devices.

The a soundcard is included in experimental setups with an <sound> element:

<sound id="sound" />

Attributes:

Name Use Description

required

Identification of the device, which is used to identify the device when it is assigned to procedures in the protocol.

Participant validation

Mon, 01 Jan 0001 00:00:00 +0000

Participants are central to how data is recorded and stored. Running an experiment with LabBench consists of collecting data from a series of participants that each is identified by an ID.

To ensure valid participant IDs, it is possible to specify their validation in the Experiment Definition File with the participant-validator element. Subject ID are validated with a regular expression that can be specified by the regex attribute of the <participant-validator> element. The <participant-validator> also has an advice attribute with text that will be displayed to the researcher if they enter an invalid ID. This attribute can be used to provide help to the operator on what is a valid participant ID in the experiment.

Researchers

Mon, 01 Jan 0001 00:00:00 +0000

LabBench uses role-based access control. When LabBench is installed, this system is disabled, meaning anyone opening LabBench has full access, including the ability to perform potentially destructive actions such as deleting data or entire studies.

For single-researcher environments or environments that can rely on computer logins, this may be acceptable. However, in multiple-researcher environments, it may be required to restrict access to certain actions, which can be accomplished by enabling the Access Control system.

LabBench JOYSTICK

Mon, 01 Jan 0001 00:00:00 +0000

This <joystick> is a standard Joystick USB device used for tasks like answering questionnaires and making ratings. It supports different button setups, each marked by its experiment ID. The button setup changes depending on the chosen procedure.

The device implements the Button, Joystick, and Trigger instruments. The Trigger instrument is a dummy implementation with no functionality, implemented by the device, so it can act as a procedure device for protocols that would otherwise require a LabBench I/O device, or be used to create protocols that can be used with both a Joystick and a LabBench I/O device.

Stimulus Rating

Mon, 01 Jan 0001 00:00:00 +0000

The stimulus rating procedure provides a way to determine the Pain Detection Threshold (PDT), the Pain Tolerance Threshold (PTT), or both with an attached button.

The procedure is executed in the same way as the stimulus-response procedure and is defined by the same parameters, with the exception that it does not have a stop-mode parameter but instead has a measurement parameter.

The procedure window for the <algometry-stimulus-rating> procedure is shown in Figure 1. The procedure window consists of two areas: applied pressure and recorded responses.

Conditioned Pain Modulation Rating

Mon, 01 Jan 0001 00:00:00 +0000

The conditioned pain modulation rating procedure is analogous to the conditioned pain modulation procedure that uses a button instead of the VAS to determine pain detection threshold (PDT), pain tolerance threshold (PTT), or both.

The same parameters define the procedure as the conditioned pain modulation procedure, with the addition of the measurement parameter that defines how the button is used to determine PDT, PTT, or both.

The procedure window for the <algometry-conditioned-pain-modulation-rating> procedure is shown in Figure 1. The procedure window consists of two areas: applied pressure and recorded responses.

Devices

Mon, 01 Jan 0001 00:00:00 +0000

The Devices page in the LabBench Runner makes it possible to add, monitor, and remove devices from the system. Before protocols can be installed as experiments on LabBench systems, you must first add the devices required by the protocol.

Managing devices is performed on the Devices page in LabBench Designer:

Adding devices

To add a device to LabBench, select the type of device to add from the list of device types on the left half of the Devices Page, then click the Add Devices button.

Image Canvas

Mon, 01 Jan 0001 00:00:00 +0000

ImageCanvas is a lightweight, stateful 2D drawing surface used in LabBench protocols to construct precise and reproducible visual stimuli. It provides an immediate-mode graphics API that separates styling, geometry, text, and image export, allowing complex stimuli to be built procedurally with clear intent. The canvas maintains an internal drawing state that applies consistently across operations and can be exported seamlessly as image data or LabBench assets.

An ImageCanvas can be created with one of the GetCanvas() functions in the Image toolkit. Below is an example, where an ImageCanvas is created to generate and display a visual stimulus for the Stroop Task:

LabBench I/O

Mon, 01 Jan 0001 00:00:00 +0000

LabBench DISPLAY

Mon, 01 Jan 0001 00:00:00 +0000

The LabBench DISPLAY defines a fixed, always-on-top window on a monitor connected to the laboratory computer. Within an experiment, this window supports multiple instruments based on the selected procedure. Each instrument defines the experiment-setup-id that activates it, and each procedure specifies which experiment-setup-id will be used while it is selected.

The LabBench DISPLAY is included in experimental setups with an <display> element:

<display id="display" normative-distance="40"> 
    <typography active-colour="rgb(255,0,0)"
                inactive-colour="rgb(128,128,128)"
                foreground-colour="rgb(0,0,0)"
                background-colour="rgb(255,255,255)">
        <!-- Content omitted for brevity -->
    </typography>

    <configurations>
        <image-display id="image" 
            experimental-setup-id="image"
            background-colour="rgb(255,255,255)" />

        <questionnaire id="questionnaire" 
            experimental-setup-id="questionnaire" 
            controller-device="joystick" />

        <visual-analogue-scale id="vas" 
            experimental-setup-id="vas" 
            controller-device="joystick" 
            length="10">
            <!-- Content omitted for brevity -->
        </visual-analogue-scale>

        <numerical-scale id="nrs" 
            experimental-setup-id="nrs" 
            controller-device="joystick" 
            minimum="0" 
            maximum="10">
            <!-- Content omitted for brevity -->
        </numerical-scale>

        <categorical-scale id="crs" 
            experimental-setup-id="crs"  
            controller-device="joystick">
            <!-- Content omitted for brevity -->
        </categorical-scale>                    

        <composite-scale id="scales" 
            experimental-setup-id="cscale"  
            controller-device="joystick">
            <!-- Content omitted for brevity -->
        </composite-scale>
    </configurations>
</display>

Attributes:

Languages and Localization

Mon, 01 Jan 0001 00:00:00 +0000

Localization refers to adapting software to suit a specific region or culture, typically involving language, cultural norms, and regional preferences. Most importantly, this involves that subject-facing text is displayed in a language that the subject understands, but it may also involve customizing other aspects of the protocol, such as formats for dates, numbers, currency, and similar culture dependent items.

Localization goes beyond mere translation and often requires a deep understanding of the subject’s culture. For example, localizing questionnaires goes beyond a translation of the text in the questionnaire but also requires a validation that the translated text holds the same meaning to the subject as the original language of the questionnaire to native speakers.

Protocol properties

Mon, 01 Jan 0001 00:00:00 +0000

The behavior of a protocol when LabBench Runner executes it can be controlled with the use of protocol properties.

Protocol properties is specified with the <properties> element in the <protocol> element of experiment definition files:

<properties>
   <rerun-policy message="[The message to be displayed to the operator]" 
                 require-reason="[true or false]"
                 force-warning="[true or false]" />
   <incomplete-protocol-warning value="[true or false]" />
   <allow-in-session-participant-creation value="[Required: true or false]" />
   <in-session-display-of-participants value="[Required: true or false]" />
</properties>

Re-run policy

The data set for a subject can store one result for each test in a protocol. If a test is rerun the previous result is replaced with the new result from the rerun. The <rerun-policy> element determines how LabBench Runner will handle rerunning tests in the protocol.

Sessions

Mon, 01 Jan 0001 00:00:00 +0000

Protocols can be devided up into multiple sessions that typically are repeated at different time points/days during the study. When sessions are defined in a protocol each test in the protocol must specify which session it belongs to with its session attribute.

Multi-session protocols are created by including a <sessions> element in the Experiment Definition File:

<sessions>
   <session id="SES01" name="Session 1" />
   <session id="SES02" name="Session 2" />
</sessions>

The <sessions> element consists of a series of <session> elements that each define a session in the protocol. Each <session> must specify two attributes; id which is the unique identifier (ID) that is used within the protocol to identify the session, and name which is the name of the session that will be shown to the experimenter when (s)he must choose which session to perform when the LabBench Runner executes the protocol.

Button

Mon, 01 Jan 0001 00:00:00 +0000

Represents a button-based response device used to capture discrete participant inputs (press/release events, active states, and reaction times).

Availability:

context.Instruments.<ButtonName>

Properties

Name	Type	Description
`ReactionTime`	`float`	Reaction time associated with the most recent latched button activation (typically milliseconds).
`Activations`	`List[IButtonActivation]`	List of recorded button activation events (press/release with timestamps).

Methods

Name	Signature	Description
`Reset`	`Reset()` → `None`	Resets the button state and clears latched/active states.
`GetActive`	`GetActive()` → `str`	Returns the currently active (pressed) button as a string.
`IsActive`	`IsActive(button: str)` → `bool`	Returns `True` if the specified button is currently pressed.
`GetLatched`	`GetLatched()` → `str`	Returns the latched button (first detected press since last reset).
`IsLatched`	`IsLatched(button: str)` → `bool`	Returns `True` if the specified button is latched.

Button identifiers

Button methods that take a button: str argument expect specific string literals. These correspond to physical buttons or logical controls.

Cold Pressor

Mon, 01 Jan 0001 00:00:00 +0000

The cold pressor procedure measures pain detection (PDT) and/or pain tolerance (PTT) based on timed button presses during hand immersion in cold water. The procedure is event-driven and records the time between key events: immersion, pain onset, and withdrawal.

During execution, instructions are presented to guide the operator or participant through the task. Button presses mark transitions between phases, and timing is recorded automatically.

After completion, the result is visualized as a timeline, showing the measured thresholds and overall duration of the procedure.

Development tools

Mon, 01 Jan 0001 00:00:00 +0000

For writing Experiment Definition Files, as well as Python scripts, an Integrated Development Environment (IDE) makes the process significantly easier due to code completion. Code completion means that you do not need to remember which XML elements or attributes are valid at a given place in your definition file. Instead, tap CTRL + SPACE (for Visual Studio Code) to get a list of valid elements or attributes Figure 1. Code completion also reduces the need for manual typing, as you can simply select the required element or attribute and then press enter, at which point the IDE will complete the code for you without requiring typing.

Image Display

Mon, 01 Jan 0001 00:00:00 +0000

Provides visual stimulus presentation by displaying images on a screen with optional timing and fiducial marking.

Availability:

context.Instruments.<ImageDisplayName>

Properties

Name	Type	Description
`Width`	`int`	Width of the display in pixels.
`Height`	`int`	Height of the display in pixels.

Methods

Name	Signature	Description
`Default`	`Default(image)` → `None`	Sets the default image shown when the display is cleared.
`Display`	`Display(image, fiducial=False)` → `None`	Displays an image immediately. If `fiducial=True`, marks the frame for synchronization.
`Display`	`Display(image, time, fiducial=False)` → `None`	Displays an image for a fixed duration (`time` in milliseconds). Optionally marks the frame with a fiducial.
`Clear`	`Clear()` → `None`	Clears the current image and restores the default image (if defined).

Typical usage example

display = context.Instruments.ImageDisplay

# Query display size
width = display.Width
height = display.Height

# Set default background
display.Default(background_image)

# Show stimulus
display.Display(stimulus_image, 200, fiducial=True)

# Clear display
display.Clear()

Notes / gotchas

Image format (LabBenchImage) must match the expected format of the instrument (not validated here).
time is specified in milliseconds.
Fiducial marking is typically used for synchronization with external devices.
Clear() restores the default image if one has been set; otherwise behavior depends on the device.
Display calls are immediate; timing precision depends on the underlying hardware and system.

Image Engine

Mon, 01 Jan 0001 00:00:00 +0000

The ImageEngine class provides a fluent, in-memory image processing pipeline for modifying bitmap images using masks, color transformations, and compositing operations. It allows loading an image, selectively replacing or isolating colors, overlaying additional images, and finally exporting the result as a LabBench image asset, all while operating directly on pixel data for efficient, repeatable transformations.

An ImageEngine is created with the GetImageEngine(image) function in the Image toolkit. In the example below, two ImageEngine objects are created; one in the constructor __init__ of the TimeSlotInstruction class that creates image masks that can later be used to replace colors in the image, and one in the Generate() function which is used to inform the operator where to apply a cream and where to perform an assessment:

Installation

Mon, 01 Jan 0001 00:00:00 +0000

Download installer

The installer can be downloaded from:

LabBench Downloads

Installation

The installation progress is automated, and requires one choice that depends on whether you have administrative access to the computer. The installation progress is illustrated in Figure 1.

Figure 1

License and installation path

When the installer starts, it will first ask you to choose the installation path and to review and accept the license. Accept the default installation path, unless your organisation have special requirements for the installation location of programs.

Interval Scale

Mon, 01 Jan 0001 00:00:00 +0000

Represents a numerical rating scale with discrete, equally spaced values. Used to collect interval-based responses such as Likert or numerical rating scales.

Availability:

context.Instruments.<IntervalScaleName>

Properties

Name	Type	Description
`Maximum`	`int`	Maximum value of the scale.
`Minimum`	`int`	Minimum value of the scale.

Methods

Name	Signature	Description
`GetCurrentRating`	`GetCurrentRating()` → `int`	Returns the current rating selected on the scale.
`GetIntervalRating`	`GetIntervalRating()` → `int`	Returns the current rating value (same scale domain as `Minimum` to `Maximum`).
`SetIntervalRating`	`SetIntervalRating(rating: int)` → `None`	Sets the current rating on the scale. Updates the device state.

Typical usage example

scale = context.Instruments.IntervalScale

# Read current rating
rating = scale.GetCurrentRating()

# Set rating programmatically
scale.SetIntervalRating(5)

# Access scale bounds
min_val = scale.Minimum
max_val = scale.Maximum

Notes / gotchas

Valid rating values are within [Minimum, Maximum]; behavior outside this range is undefined.
SetIntervalRating directly modifies the device state and may affect participant interaction.
GetCurrentRating and GetIntervalRating return integer values; no fractional ratings are supported.

Joystick

Mon, 01 Jan 0001 00:00:00 +0000

Provides access to a joystick input device, allowing continuous sampling of its position along one or more axes.

Availability:

context.Instruments.<JoystickName>

Properties

No public properties.

Methods

Name	Signature	Description
`Read`	`Read()` → `JoystickPosition`	Returns the current joystick position as a `JoystickPosition` object containing axis values.

JoystickPosition

Represents the current position of the joystick.

Properties

Name	Type	Description
`X`	`float`	Position along the X-axis (horizontal).
`Y`	`float`	Position along the Y-axis (vertical).
`Z`	`float`	Position along the Z-axis (e.g., rotation or throttle, if available).

Typical usage example

joystick = context.Instruments.Joystick

pos = joystick.Read()

x = pos.X
y = pos.Y
z = pos.Z

Notes / gotchas

Axis ranges and scaling are device-dependent (no normalization guaranteed).
Z may not be meaningful on all devices.
Sampling is pull-based; call Read() each time a new value is needed.

Keyboard

Mon, 01 Jan 0001 00:00:00 +0000

The Keyboard Toolkit provides a simple, deterministic way to handle keyboard input in LabBench experiments by exposing a latched key state rather than transient key-down events. It continuously monitors the system keyboard, records which keys have been pressed, and allows experiment logic to query those presses using clear, string-based key identifiers. Key presses remain available until explicitly cleared.

Keyboard Toolkit

The Keyboard Toolkit provides a simple, robust way to handle keyboard input in LabBench experiments, especially when controlling trial flow from Python via IronPython. Instead of reacting to instantaneous key-down events, the toolkit exposes a latched key state model. Once a key press is detected, it remains available to your code until you explicitly clear it.

LabBench CPAR+

Mon, 01 Jan 0001 00:00:00 +0000

Manual Threshold Estimation

Mon, 01 Jan 0001 00:00:00 +0000

The manual threshold estimation procedure is used when LabBench cannot control the stimulus directly, and the experimenter must apply it manually. It consists of a response task and an estimation algorithm: the participant performs a perception task in which responses are classified as correct or incorrect, and an adaptive algorithm uses these outcomes to update estimates of the threshold or psychometric function. The stimulus is implicitly defined by the response task, and estimation is performed over an independent variable (x), where increasing x is assumed to increase the probability of a correct response.

Ordinal Scale

Mon, 01 Jan 0001 00:00:00 +0000

Represents a categorical rating scale where responses are selected from ordered categories without assuming equal spacing between them.

Availability:

context.Instruments.<OrdinalScaleName>

Properties

Name	Type	Description
`NumberOfCategories`	`int`	Total number of categories available on the scale.
`Categories`	`List[IAnchor]`	List of category definitions (labels and enabled state).

Methods

Name	Signature	Description
`GetSelectedCategory`	`GetSelectedCategory()` → `int`	Returns the currently selected category index.
`SetSelectedCategory`	`SetSelectedCategory(category: int)` → `None`	Sets the selected category by index. Updates the device state.

Category (`IAnchor`)

Represents a single category on the ordinal scale.

Persistent variables

Mon, 01 Jan 0001 00:00:00 +0000

Persistent variables share characteristics with variables and can be used throughout a protocol wherever a variable can be used. However, unlike variables that are created each time a session is started, persistent variables are only created once when a participant is created and stay invariant for all sessions in a protocol. Furthermore, persistent variables are saved to the resulting data set and are available for data analysis scripts. Saving to the data set means that persistent variables have restrictions on their types, whereas variables can be of any type created by Python code. Persistent variables <persistent-variables> are primarily intended for randomizing protocol elements, but they can be used for any purpose.

Pressure Algometer

Mon, 01 Jan 0001 00:00:00 +0000

The PressureAlgometer instrument represent an abstraction of computerised cuff pressure algometry devices.

context.Instruments.PressureAlgometer

String Literals

Outlet

Value	Definition
`'outlet-1'`	Pressure outlet 1
`'outlet-2'`	Pressure outlet 2

Channel

Value	Definition
`'none'`	Used for declaring no waveform channel is mapped to an outlet.
`'channel-1'`	Waveform channel 1.
`'channel-2'`	Waveform channel 2.

Criterion

Value	Definition
`'stop-on-maximal-rating'`	Stimulation will stop on a VAS of 10cm.
`'stop-when-button-pressed'`	Stimulation will stop when the button is pressed.
`'stop-when-button-released'`	Stimulation will stop when the button is released.

Properties

Name	Type	Description
`CompressorMode`	`AlgometerCompressorMode`	Compressor operation mode (`auto` or `manual`).
`MaximalPressure`	`double`	Maximum pressure the device can generate.
`Pressure`	`double[]`	Current pressure values per channel.
`UpdateRate`	`double`	Update rate for pressure generation.
`SamplePeriod`	`double`	Sampling period for pressure and ratings.
`State`	`AlgometerState`	Current device state.
`DeviceError`	`string`	Error message if the device cannot start stimulation.
`SupplyPressure`	`double`	Current supply pressure.
`FinalRating`	`double`	Final VAS rating after stimulation.
`Rating`	`double`	Current VAS rating.
`VasConnected`	`bool`	Indicates if a VAS device is connected.
`VasReady`	`bool`	Indicates if the VAS device is ready.
`PressureAvailable`	`bool`	Indicates if sufficient pressure is available.
`StopCondition`	`AlgometerStopCondition`	Stop condition that ended the stimulation.
`NumberOfPressureChannels`	`int`	Number of available pressure channels.
`Channels`	`IList<IPressureChannel>`	Available pressure channels.

Methods

Name	Signature	Description
`GetCompressorMode`	`GetCompressorMode()` → `str`	Returns compressor mode as string (`"auto"` or `"manual"`).
`GetState`	`GetState()` → `str`	Returns current state as string.
`GetStopCondition`	`GetStopCondition()` → `str`	Returns stop condition as string.
`ResetAlgometer`	`ResetAlgometer()`	Resets device configuration to default.
`ConfigurePressureOutput`	`ConfigurePressureOutput(outlet, channel)`	Maps a pressure channel to an outlet.
`StartStimulation`	`StartStimulation(criterion, forcedStart, externalTrigger=False)`	Starts pressure stimulation with specified stop criterion.
`StopStimulation`	`StopStimulation()`	Stops pressure stimulation.
`StartUpdates`	`StartUpdates()`	Starts streaming updates from the device.
`StopUpdates`	`StopUpdates()`	Stops streaming updates.
`GetUpdates`	`GetUpdates()` → `list`	Returns collected update data.
`GetTime`	`GetTime(sample)` → `float`	Returns time corresponding to a sample index.

Typical usage

alg = context.Instruments.PressureAlgometer
alg.StartStimulation("stop-on-maximal-rating", forcedStart=False)

# Read current rating
rating = alg.Rating

alg.StopStimulation()

Pressure Channel (`IPressureChannel`)

Represents a single pressure output channel capable of executing stimulus programs.

Psychophysics

Mon, 01 Jan 0001 00:00:00 +0000

Provides builders for configuring psychophysical estimation methods (Psi, Up-Down, Discrete Up-Down) and access to predefined psychometric functions.

Availability:

context.Psychophysics

Properties

Name	Type	Description
`Functions`	`FunctionsToolkit`	Factory for creating psychometric functions (e.g., Logistic, Weibull).

Methods

Name	Signature	Description
`PsiMethod`	`PsiMethod() -> PsiMethodCreator`	Creates a builder for configuring a Psi method.
`UpDownMethod`	`UpDownMethod() -> UpDownMethodCreator`	Creates a builder for configuring an up-down method.
`DiscreteUpDownMethod`	`DiscreteUpDownMethod() -> DiscreteUpDownMethodCreator`	Creates a builder for configuring a discrete up-down method.

Typical usage example

# Create a Psi method
psi = context.Psychophysics.PsiMethod() \
    .NumberOfTrials(40) \
    .Alpha(0.1, 1.0, 10) \
    .Beta(0.5, 5.0, 10) \
    .Intensity(0.1, 1.0, 20) \
    .Function(context.Psychophysics.Functions.Logistic()) \
    .Create()

# Create an up-down method
ud = context.Psychophysics.UpDownMethod() \
    .Up(1) \
    .Down(2) \
    .StepSize(0.1) \
    .StartIntensity(0.5) \
    .Function(context.Psychophysics.Functions.Weibull()) \
    .Create()

Psi Method Creator (`PsiMethodCreator`)

Description

Builder for configuring a Psi adaptive psychophysical method.

Questionnaire

Mon, 01 Jan 0001 00:00:00 +0000

Questionnaires makes it possible to collect input during an experimental session. Conceptually, a questionnaire is a sequence of predefined questions that can be presented either to the operator or both the participant and operator, depending on the purpose of the questionnaire.

While questionnaires naturally support classical psychometric instruments (e.g., standardised scales and surveys), their role in LabBench extends beyond this.

In addition to their role as Questionnaires, they can also function as a general-purpose interface for structured data entry, enabling:

Ratio Scale

Mon, 01 Jan 0001 00:00:00 +0000

Represents a continuous rating scale (e.g., Visual Analog Scale) where responses are given as a real-valued position along a defined length.

Availability:

context.Instruments.<RatioScaleName>

Properties

Name	Type	Description
`Length`	`float`	Total length of the scale. Defines the maximal possible rating value.

Methods

Name	Signature	Description
`GetCurrentRating`	`GetCurrentRating()` → `float`	Returns the current rating value on the scale.
`GetRatioRating`	`GetRatioRating()` → `float`	Returns the current rating value (same scale domain as `0` to `Length`).
`SetRatioRating`	`SetRatioRating(rating: float)` → `None`	Sets the current rating on the scale. Updates the device state.

Typical usage example

scale = context.Instruments.RatioScale

# Read current rating
rating = scale.GetCurrentRating()

# Set rating programmatically
scale.SetRatioRating(5.0)

# Access scale length
max_val = scale.Length

Notes / gotchas

Valid rating values are typically within [0, Length]; behavior outside this range is undefined.
Ratings are continuous (floating-point), unlike interval or ordinal scales.
SetRatioRating directly modifies the device state and may affect participant interaction.
GetCurrentRating and GetRatioRating return equivalent values.

Response Recording

Mon, 01 Jan 0001 00:00:00 +0000

The response recording test implements computerized psychophysical ratings that allow a subject to rate a sensation sampled continuously for either a fixed time or a time determined by events during the test. Computerized psychophysical ratings allow time-dependent quantification of psychophysiological responses, such as the area under the curve, the maximal rating, or the time of maximal rating. Optionally, the test can be amended to include simultaneous recording of signals, either stimuli (e.g., stimulation pressure) or biophysical signals (e.g., heart rate or galvanic skin response). It is also possible to define events that can occur during the test; this will allow the experimenter to mark the times these events occur in the test’s recorded data.

Scales

Mon, 01 Jan 0001 00:00:00 +0000

Represents a composite rating device that provides access to multiple rating scales simultaneously.

Availability:

context.Instruments.<ScalesName>

Properties

Name	Type	Description
`Scales`	`List[IRatingScale]`	Collection of rating scale instances available on the device. Each element implements a specific scale type (e.g., ratio, interval, ordinal).

Methods

Name	Signature	Description
`InitializeRating`	`InitializeRating()` → `None`	Initializes or resets all contained rating scales. Typically prepares the device for a new rating session.

Typical usage example

scales = context.Instruments.Scales

# Initialize all scales
scales.InitializeRating()

# Access individual scales
for scale in scales.Scales:
    # Use scale depending on its type
    pass

Notes / gotchas

The specific type of each scale in Scales depends on the experimental setup.
Access to scale-specific methods requires knowledge of the concrete scale type.
InitializeRating() should typically be called before collecting responses.

Scheduler

Mon, 01 Jan 0001 00:00:00 +0000

The scheduling toolkit allows you to run tasks in the background while your protocol is running. Running tasks in the background makes it possible, for example, to update visual stimuli on a LabBench DISPLAY asynchronously with precise timing during tests such as <sequential> or <sequence> tests.

Scheduler

Function: `Create()`

Returns a new created Schedule which can be used to create a schedule of tasks that can later be run with the Run function.

Sequential

Mon, 01 Jan 0001 00:00:00 +0000

The sequential procedure enables state machines to implement experimental procedures. Unlike most other procedures, it has no base functionality that can be configured in the LabBench Language; instead, its functionality must be implemented by a Python script that is called from its procedure events and state events.

The purpose of the sequential procedure is to allow you to define procedures for which there is no ready-made LabBench procedure. Consequently, it is fundamentally different from all other LabBench procedures: whereas other LabBench procedures allow you to extend their functionality with Python code, the functionality of a sequential procedure must be implemented in Python.

Sound Player

Mon, 01 Jan 0001 00:00:00 +0000

Provides audio stimulus playback by sending waveform data to an output device.

Availability:

context.Instruments.<SoundPlayerName>

Properties

No public properties.

Methods

Name	Signature	Description
`Play`	`Play(waveform: bytes)` → `None`	Plays a waveform provided as raw byte data.
`Play`	`Play(waveform: Waveform)` → `None`	Plays a single waveform object on the default output channel.
`Play`	`Play(waveforms: List[Waveform])` → `None`	Plays multiple waveforms simultaneously, where each waveform is mapped to a separate output channel (first → channel 1, second → channel 2, etc.).
`Playsc`	`Playsc(waveform: Waveform)` → `None`	Plays a waveform scaled to full output amplitude on the default channel.
`Playsc`	`Playsc(waveforms: List[Waveform])` → `None`	Plays multiple waveforms scaled to full output amplitude, each assigned to separate output channels.

Typical usage example

player = context.Instruments.SoundPlayer

# Play a single waveform on all output channels.
player.Play(waveform)

# Play on multiple channels
player.Play([waveform_left, waveform_right])

# Play scaled waveform on all output channels.
player.Playsc(waveform)

Notes / gotchas

When passing a list, each waveform is assigned to a separate channel in order.
Playsc scales waveforms to full output amplitude before playback.
Waveform format must match the expectations of the underlying device.
Playback is triggered immediately when calling the method.
Channel count is determined by the number of waveforms provided.

Stimulation Sequence

Mon, 01 Jan 0001 00:00:00 +0000

The <stimulation-sequence> procedure generates stimulus sequences for evoked potentials, behavioural tasks, or similar procedures. Construct the sequence by creating a stimulus pattern to control timing and a stimulus set to define which stimuli are delivered.

The stimulation pattern <stimulation-pattern>is constructed from a composition of sequences, which can be deterministic or random. However, to use this procedure, the stimulation pattern (number of stimuli and randomisation) is generated when the procedure starts. Consequently, it is not possible to change the stimulation pattern while the procedure is running, so it cannot depend on participant performance during the procedure. Use the <sequential> procedure if the stimulation pattern depends on the participant, as that procedure is more versatile but also more complex to implement than this stimulation sequence procedure.

Stimulator

Mon, 01 Jan 0001 00:00:00 +0000

Provides generation of physical stimuli (e.g., electrical, thermal, mechanical) based on defined stimulus waveforms, with configurable triggering and output control.

Availability:

context.Instruments.<StimulatorName>

Properties

Name	Type	Description
`Modality`	`Modality`	Type of stimulus modality (e.g., electrical, pressure).
`Unit`	`Unit`	Unit of the stimulus intensity (e.g., mA, °C).
`Imax`	`float`	Maximum allowed stimulus intensity.
`Max`	`float`	Alias for maximum intensity.
`Imin`	`float`	Minimum allowed stimulus intensity.
`Min`	`float`	Alias for minimum intensity.
`Ineutral`	`float`	Neutral (baseline) intensity level.
`Neutral`	`float`	Alias for neutral intensity.
`Range`	`float`	Range of valid stimulus intensities (`Max - Min`).

Methods

Name	Signature	Description
`GetModality`	`GetModality()` → `str`	Returns the modality as a string.
`Initialize`	`Initialize(setup: IStimulatorSetup)` → `None`	Initializes the stimulator with a specific setup configuration.
`Generate`	`Generate(stimulus: IStimulus)` → `None`	Generates a stimulus using the device’s default trigger and update rate.
`Generate`	`Generate(startTrigger: str, stimulus: IStimulus)` → `None`	Generates a stimulus when triggered by the specified trigger source.
`Generate`	`Generate(startTrigger: str, restart: bool, stimulus: IStimulus)` → `None`	Generates a stimulus with explicit control over trigger source and restart behavior.
`SetDefaultOutput`	`SetDefaultOutput(value: float)` → `None`	Sets the default output level when no stimulus is active.

Trigger source (`startTrigger`)

The startTrigger argument specifies how stimulus generation is triggered.

Stimuli

Mon, 01 Jan 0001 00:00:00 +0000

Provides programmatic construction of stimuli (pulse, ramp, sine, arbitrary, combined, repeated, multi-channel, and segmented waveforms).

Availability:

context.Stimuli

Properties

No public readable properties are defined.

Methods

Name	Signature	Description
`Pulse`	`Pulse(Is: float, Ts: float) -> PulseValueStimulus`	Creates a rectangular pulse with intensity `Is` and duration `Ts`.
`Pulse`	`Pulse(Is: float, Ts: float, Tdelay: float) -> PulseValueStimulus`	Same as above with delay `Tdelay`.
`Ramp`	`Ramp(intensity: float, duration: float) -> RampValueStimulus`	Creates a linear ramp stimulus.
`Ramp`	`Ramp(intensity: float, duration: float, delay: float) -> RampValueStimulus`	Ramp with delay.
`Ramp`	`Ramp(intensity: float, duration: float, delay: float, offset: float) -> RampValueStimulus`	Ramp with delay and offset.
`Sine`	`Sine(intensity: float, duration: float, frequency: float) -> SineValueStimulus`	Creates a sinusoidal stimulus.
`Sine`	`Sine(intensity: float, duration: float, frequency: float, delay: float) -> SineValueStimulus`	Sine with delay.
`Arbitrary`	`Arbitrary(expression: Callable[[float], float], duration: float) -> ArbitraryValueStimulus`	Creates a stimulus from a time-dependent function.
`Arbitrary`	`Arbitrary(expression: Callable[[float], float], duration: float, delay: float) -> ArbitraryValueStimulus`	Same with delay.
`Combined`	`Combined() -> CombinedValueStimulus`	Creates a stimulus that sums multiple stimuli.
`Repeated`	`Repeated(stimulus: IStimulus, repetitions: int, period: float, delay: float) -> RepeatedValueStimulus`	Repeats a stimulus with period and delay.
`Repeated`	`Repeated(stimulus: IStimulus, repetitions: int, period: float) -> RepeatedValueStimulus`	Repeats a stimulus with period.
`Multiple`	`Multiple() -> MultipleOutputValueStimulus`	Creates a multi-channel stimulus.
`LinearStimulus`	`LinearStimulus() -> LinearSegmentValueStimulus`	Creates a piecewise linear stimulus.

Typical usage example

stim = context.Stimuli

# Simple pulse
pulse = stim.Pulse(1.0, 5.0)

# Combined stimulus
combined = stim.Combined() \
    .Add(stim.Pulse(1.0, 5.0)) \
    .Add(stim.Sine(0.5, 10.0, 100))

# Repeated stimulus
rep = stim.Repeated(pulse, 5, 20.0)

# Arbitrary waveform
arb = stim.Arbitrary(lambda t: t * 0.1, 50.0)

Combined Stimulus (`CombinedValueStimulus`)

Description

Represents a stimulus formed by summing multiple stimuli.

Stimulus Presentation

Mon, 01 Jan 0001 00:00:00 +0000

The Stimulus Presentation procedure allows a participant to become familiar with a stimulus and to rate its sensation on a psychophysical rating scale.

The procedure can also be used to manually find thresholds, as the last tested intensity is available in the calculated parameter [ProcedureID].Intensity upon completion.

The procedure window for the procedure is shown in Figure 1. It consists of three main areas: responses, stimulus display, and stimulation and intensity control.

Threshold Estimation

Mon, 01 Jan 0001 00:00:00 +0000

The threshold estimation test uses adaptive methods to efficiently estimate a participant’s perceptual threshold or full psychometric function. Instead of presenting a fixed set of stimulus intensities, adaptive methods adjust stimulus levels in real time based on the participant’s responses. Adaptive methods allow the experimenter to concentrate trials around the most informative stimulus range—typically near the participant’s threshold—thereby reducing the total number of trials needed compared to non-adaptive (e.g., method of constant stimuli) approaches.

Trigger Detector

Mon, 01 Jan 0001 00:00:00 +0000

Detects incoming trigger events and provides information about trigger state, timing, and count.

Availability:

context.Instruments.<TriggerDetectorName>

Properties

Name	Type	Description
`IsTriggered`	`bool`	Indicates whether a trigger event has been detected.
`Latency`	`float`	Latency associated with the detected trigger (unit depends on device, typically milliseconds).
`Count`	`int`	Number of detected trigger events since last reset.

Methods

Name	Signature	Description
`Reset`	`Reset()` → `None`	Resets the trigger detector state, clearing trigger flags and counters.

Typical usage example

detector = context.Instruments.TriggerDetector

# Check trigger state
if detector.IsTriggered:
    print("Trigger detected with latency:", detector.Latency)

# Read number of triggers
count = detector.Count

# Reset between trials
detector.Reset()

Notes / gotchas

Reset() should typically be called between trials to clear previous trigger events.
Latency is only meaningful when a trigger has been detected.
Trigger detection depends on correct hardware configuration and signal routing.

Trigger Generator

Mon, 01 Jan 0001 00:00:00 +0000

Generates trigger sequences for synchronization, event marking, or control of external devices.

Availability:

context.Instruments.<TriggerGeneratorName>

Properties

No public readable properties are defined.

Methods

Name	Signature	Description
`GenerateTriggerSequence`	`GenerateTriggerSequence(startTrigger: str, triggers: List[ITrigger]) -> None`	Generates a trigger sequence when the specified trigger source occurs.
`GenerateTriggerSequence`	`GenerateTriggerSequence(startTrigger: str, restart: bool, triggers: List[ITrigger]) -> None`	Same as above, with control over whether an ongoing sequence should be restarted.

Parameters

startTrigger (str) Defines when the trigger sequence should start. Supported values:

Triggers

Mon, 01 Jan 0001 00:00:00 +0000

Provides programmatic construction of trigger signals and trigger sequences for synchronization and event marking.

Availability:

context.Triggers

Properties

No public readable properties are defined.

Methods

Name	Signature	Description
`Sequence`	`Sequence() -> TriggerSequence`	Creates a container for building a trigger sequence.
`CreateTrigger`	`CreateTrigger(duration: float) -> ValueTrigger`	Creates a trigger with a specified duration.

Typical usage example

trg = context.Triggers

trigger = trg.CreateTrigger(1.0) \
    .TriggerOut() \
    .Interface(16)

sequence = trg.Sequence() \
    .Add(trigger)

# sequence can be passed where ITrigger[] is expected

Trigger Sequence (`TriggerSequence`)

Description

Represents an ordered collection of triggers that can be passed as a trigger array.

Variables

Mon, 01 Jan 0001 00:00:00 +0000

Variables can be used in calculated and dynamic text attributes, and Python scripts throughout a protocol. They enable the specification of parameters for test configuration (i.e., attribute values) that can be reused for multiple attributes, thereby eliminating the need for duplicate values. They also provide a convenient method for creating and using Python classes from single-line Python statements within Experiment Definition Files or from functions that are called from Python scripts. Python classes can significantly simplify the programming of advanced protocols.

Waveforms

Mon, 01 Jan 0001 00:00:00 +0000

Provides utilities for creating and generating waveform objects for use in stimulus generation and playback.

Availability:

context.Waveforms

Properties

No public readable properties are defined.

Methods

Name	Signature	Description
`Arbitrary`	`Arbitrary(values: Iterable[float]) -> Waveform`	Creates a waveform from a sequence of sample values.
`Zero`	`Zero(length: int) -> Waveform`	Creates a waveform with all samples set to 0.
`Ones`	`Ones(length: int) -> Waveform`	Creates a waveform with all samples set to 1.
`Sin`	`Sin(amplitude: float, frequency: float, phase: float, length: float, rate: float) -> Waveform`	Creates a sinusoidal waveform and sets its sample rate.
`WhiteNoise`	`WhiteNoise(amplitude: float, length: int) -> Waveform`	Creates white noise in range `[-amplitude, amplitude]`.

Typical usage example

wf = context.Waveforms

w1 = wf.Arbitrary([0.0, 0.5, 1.0])
w2 = wf.Sin(1.0, 5.0, 0.0, 1000, 1000)
w3 = wf.WhiteNoise(0.2, 1000)

w = (w2 + w3).Normalize().SetSampleRate(2000)

Notes / gotchas

Arithmetic operations require equal waveform length.
Default sample rate is 1000 Hz unless changed.
Many operations return new waveform instances.
White noise is non-deterministic.

Waveform (`Waveform`)

Description

Represents a sampled signal with associated timing, metadata, and signal processing operations.

CSV Export

Mon, 01 Jan 0001 00:00:00 +0000

Defines a post-session action that exports participant data to a CSV file.
Executed after a participant session or across multiple sessions (batch mode).
Supports dynamic file naming, conditional value evaluation, and culture-specific formatting.
Writes a single row per session, or multiple rows when executed in batch mode.

Definition

The post-session action is defined with:

        <export-to-csv name="Export to CSV" 
            location="C:\LabBenchExport\intro.postSessionActions" 
            filename="dynamic: f'{Participant}.csv'">
            <item name="ID" value="Participant" default="NA" />
            <item name="Participation" value="DATA.Participation" default="NA" condition="DATA.Completed" />
            <item name="Age" value="DATA.Age" default="NA" condition="DATA.Completed" />
        </export-to-csv>

and has the following attributes:

Export Data

Mon, 01 Jan 0001 00:00:00 +0000

Defines a post-session action that exports participant data to a single file.
Executes after a participant session has completed.
Produces one output file per participant.
The output format determines the file type and exporter used.

Definition

The post-session action is defined with:

<export-data name="Export data" 
            location="C:\LabBenchExport\intro.postSessionActions"
            format="json" 
            filename="dynamic: f'{Participant}.json'" />

and has the following attributes:

Attribute	Type	Specification
name	string	Identifier of the post-session action. Required. Must be non-empty.
location	string	File system directory where the exported file is written. Required. Must exist at validation time.
format	enum	Output format controlling file representation and default file extension. Supported values are defined in `ExportFormat`.
filename	string	Script expression evaluated at runtime to produce the output file name. Required. Must pass script validation.

format

Value	Description	Default Extension
json	Javescript Object Notation	json
hdf5	Hierarchical Data Format version 5	h5
matlab	Matlab File Format (Level 5)	mat

Getting started

Mon, 01 Jan 0001 00:00:00 +0000

Introduction to LabBench

This protocol is a study on the correlation between depression, anxiety and stress assessed with the DASS scale, and response inhibition measured with the Stop-Signal Task. It is written to demonstrate the capabilities of LabBench to automate experimental protocols, providing guidance to operators and participants, and for automatic processing and export of experimental data.

Introduction

The purpose of this protocol is to demonstrate how an experimental protocol can be implemented with LabBench, which is demonstrated with a protocol that studies the relationship between Depression, Anxiety and Stress, and response inhibition is implemented. Depression, Anxiety and Stress is assessed with the DASS scale from the Psychology Foundation of Australia. The DASS scale measures three related emotional states of depression, anxiety, and stress on 42-item self-report questionnaire.

Image Path

Mon, 01 Jan 0001 00:00:00 +0000

ImagePath represents a mutable vector path used to construct complex geometric shapes, trajectories, and outlines that can later be rendered onto an ImageCanvas. It is a thin, controlled wrapper around Skia’s path primitive, exposed to Python in a way that supports deterministic stimulus construction and safe resource management.

An ImagePath does not draw anything by itself. Instead, it records a sequence of path commands (moves and lines) that define geometry. The completed path is rendered explicitly using ImageCanvas.Draw(path). This makes ImagePath particularly suitable for trajectories, contours, outlines, and stimuli defined algorithmically rather than as simple primitives.

Log

Mon, 01 Jan 0001 00:00:00 +0000

Exports the experimental log of a participant to a PDF file.

Executed after a session using the post-session action system.
Reads log entries from the participant session.
Generates a formatted PDF containing filtered log entries.
Output is written to a file in the specified location.

Definition

The post-session action is defined with:

<export-log name="Log Export" 
            location="C:\LabBenchExport\intro.postSessionActions" 
            filename="dynamic: f'{Participant}.pdf'" 
            id="Inventors' Way"
            level="debug"/>

and has the following attributes:

Attribute	Type	Specification
name	string	Required. Identifier of the action. Must be non-empty.
location	string	Required. Directory where the generated PDF will be saved. Must exist at validation time.
filename	dynamic text	Required. Expression evaluated at runtime to produce the output file name.
id	dynamic text	Optional. Expression evaluated at runtime. If provided, rendered in the header of each page.
level	LogLevel	Optional. Minimum log level to include. Defaults to Information.

Mentalab Explore Pro

Mon, 01 Jan 0001 00:00:00 +0000

Protocols

Mon, 01 Jan 0001 00:00:00 +0000

To create an experiment with LabBench, you must first have a protocol. Protocols are organized into Protocol Repositories, which are configured and managed from the Protocol page in LabBench Designer (see Figure 1). A full description of Protocol Repositories is beyond the scope of this LabBench Administration guide; however, below is a short introduction to the key concepts of Protocol Repositories that are needed to manage them in LabBench Designer and create experiments from the protocols they contain.

Scripts

Mon, 01 Jan 0001 00:00:00 +0000

The <export-script> post-session action executes a calculated script after a session has completed.

Used to implement custom post-session logic using calculated parameters.
Supports execution of Python functions defined in file assets.
Integrates with the LabBench blackboard for passing execution context.
Can be executed per session or in batch across stored participants.

Execution behavior:

Sets ExportLocation and ExportName on the context before execution.
Executes the provided script expression.
Expects the script to return True on success.
Throws an exception if the script returns False.

Definition

The <export-script> element defines a script-based post-session action.

Copy file

Mon, 01 Jan 0001 00:00:00 +0000

Copies a file from a source directory to the action location.
Executed as part of the experiment action pipeline (e.g., post-session actions).
The filename is preserved; renaming is not supported.
Overwrites existing files at the destination.

Definition

The <copy> element defines a file copy operation from a source directory to the configured location.

<copy name="Copy file" 
    location="C:\LabBenchExport" 
    source="C:\LabBenchExport\intro.postSessionActions" 
    filename="dynamic: f'{Participant}.csv'" />

which has the following attributes:

Attribute	Type	Specification
name	string	Name of the action
location	string	Destination directory where the file will be copied. Must exist at execution time.
source	string	Source directory containing the file to copy. Must exist at execution time.
filename	dynamic text	Must resolve to the filename (not path). Required.

Experiments

Mon, 01 Jan 0001 00:00:00 +0000

Experiments are managed on the Experiments Page of LabBench Designer (see Figure 1). To the left, this page lists all the experiments that are currently present in the system. This list selects which experiment will be shown on the Experiment Panel on the right of the Experiments Page.

Figure 1: The Experiments Page in the LabBench Designer.

The Experiment Panel consists of tabs to the left that lets you choose between four tabs:

Font Metrics

Mon, 01 Jan 0001 00:00:00 +0000

FontMetrics provides detailed, read-only measurements describing the vertical geometry of the currently active font on an ImageCanvas. These metrics define how text is positioned relative to its baseline and how much vertical space glyphs occupy above and below it.

The metrics reflect the currently selected font and text size and are updated automatically whenever font-related properties change. They are primarily used for precise text layout, vertical alignment, and advanced positioning scenarios where semantic alignment alone is not sufficient.

Introduction to XML

Mon, 01 Jan 0001 00:00:00 +0000

The Experiment Definition File is a plain text file, which means any text editor can be used. The format for these files is based on the eXtensible Markup Language (XML), a general-purpose markup language that can be used to implement domain specific languages, such as in this case the LabBench Language for Experiment Definition Files.

The code listing below provides the structure of an Experiment Definition File:

<?xml version="1.0" encoding="UTF-8"?>
<experiment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:noNamespaceSchemaLocation="https://files.labbench.io/xsd/6.0/experiment.xsd">
    <participant-validator regex="^S[0-9]{3}$|^TEST[0-9]{3}$"
                       advice="Please enter an ID in the form of SXXX, where X is a digit" />
    <experimental-setup-variants default="SetupID">
        <experimental-setup id="SetupID" name="Name of experimental setup">
            <devices>
                <!--  Please see page Experimental Setups -->
            </devices>
            <device-mapping>
                <!--  Please see page Experimental Setups -->
            </device-mapping>
        </experimental-setup>    
    </experimental-setup-variants>
    <protocol>
        <languages>
          <!--  Please see page Languages and Localization -->
        </languages>
        <sessions>
          <!--  Please see page Sessions -->
        </sessions>
        <properties>
          <!--  Please see page Protocol properties -->
        </properties>
        <persistent-variables>
          <!--  Please see page Persistent variables -->
        </persistent-variables>        
        <variables>
          <!--  Please see page Variables -->
        </variables>
        <templates>
              <includes>
                <!--  Please see page Templating -->
              </includes>
              <protocol-variables>
                <!--  Please see page Templating -->
              </protocol-variables>
              <template-variables>
                <!--  Please see page Templating -->
              </template-variables>
              <procedure-templates>
                <!--  Please see page Templating -->
              </procedure-templates>
              <assets>
                <!--  Please see page Templating -->
              </assets>           
        </templates>
        <procedures>
          <!--  Please see page Procedures -->
        </procedures>
        <assets>
          <!--  Contains files that are included in the protocol -->
        </assets>
    </protocol>
    <post-actions>
      <!--  Please see page Post-Session Actions -->
    </post-actions>
</experiment>

Listing 1: Structure of an experiment definition file

Joystick

Mon, 01 Jan 0001 00:00:00 +0000

ImageRectangle

Mon, 01 Jan 0001 00:00:00 +0000

Represents a rectangular region in pixel coordinates, typically returned from drawing operations (e.g. Sprite) to describe the rendered bounds.

Availability:

rect = canvas.Sprite(...)

Properties

Name	Type	Description
`Left`	`float`	Left edge of the rectangle (pixels).
`Top`	`float`	Top edge of the rectangle (pixels).
`Right`	`float`	Right edge of the rectangle (pixels).
`Bottom`	`float`	Bottom edge of the rectangle (pixels).
`Width`	`float`	Width of the rectangle (`Right - Left`).
`Height`	`float`	Height of the rectangle (`Bottom - Top`).
`CenterX`	`float`	Horizontal center of the rectangle.
`CenterY`	`float`	Vertical center of the rectangle.
`TopLeft`	`ImagePoint`	Top-left corner as a point.
`BottomRight`	`ImagePoint`	Bottom-right corner as a point.

Methods

Name	Signature	Description
`ToString`	`ToString() -> str`	Returns a string representation `[left, top, right, bottom] (W=..., H=...)`.

Typical usage example

rect = canvas.Sprite(400, 300, image_bytes, width=200)

# Use geometry for layout or alignment
cx = rect.CenterX
cy = rect.CenterY

canvas.Color("#FF0000")
canvas.Circle(cx, cy, 10)

Notes / gotchas

Coordinates are in canvas pixel space (origin at top-left).
Rectangle values reflect the final rendered position, including alignment and scaling.
Useful for layout calculations after drawing operations (e.g. centering overlays, hit-testing).
Implicit conversion to underlying drawing types is handled internally; not exposed in Python.

Sound Card

Mon, 01 Jan 0001 00:00:00 +0000

ImagePoint

Mon, 01 Jan 0001 00:00:00 +0000

Represents a 2D point in pixel coordinates, typically used for positions, geometry, and layout calculations in drawing operations.

Availability:

point = rect.TopLeft

Properties

Name	Type	Description
`X`	`float`	Horizontal coordinate in pixels.
`Y`	`float`	Vertical coordinate in pixels.

Methods

Name	Signature	Description
`From`	`From(x: float, y: float) -> ImagePoint`	Creates a point from numeric coordinates.
`ToString`	`ToString() -> str`	Returns a string representation `(x, y)`.

Typical usage example

rect = canvas.Sprite(400, 300, image_bytes)

p = rect.TopLeft

canvas.Color("#00FF00")
canvas.Point(p.X, p.Y)

Notes / gotchas

Coordinates are in canvas pixel space (origin at top-left).
Primarily used as a convenience wrapper for geometry returned from other APIs.
Can be constructed directly or obtained from objects such as ImageRectangle.
Internal conversions to underlying drawing types are handled automatically.

Subject Display

Mon, 01 Jan 0001 00:00:00 +0000

Language Specification

Mon, 01 Jan 0001 00:00:00 +0000

Experiment

Defines an entire experiment and contains the following elements:

<participant-validator>: defines the rule for valid participant/session IDs.
<experimental-setup> or <experimental-setup-variants>: defines the research equipment used in the protocol and assigns them to procedures in the protocol.
<protocol>: defines the protocol for the experiment. This protocol consists of a procedure (procedures).
<post-actions>: defines actions that should be executed when a session is completed.

Elements

Name Use Description

<participant-validator>

Nocitech CPAR

Mon, 01 Jan 0001 00:00:00 +0000

The Nocitech CPAR is a computer-controlled cuff pressure algometer that delivers precise, reproducible pressure stimulation for neuroscience research. It generates customisable piecewise-linear pressure waveforms with accurate temporal control, supporting advanced psychophysical protocols. The device enables automated cuff pressure algometry protocols that are not feasible with manual devices.

The Nocitech CPAR device is included in experimental setups with an <cpar> element:

<cpar id="cpar" compressor-mode="auto"/>

Attributes:

Name Use Description

required

Identification of the device, which is used to identify the device when it is assigned to procedures in the protocol.

Markdown

Mon, 01 Jan 0001 00:00:00 +0000

This is a placeholder page. Replace it with your own content.

Text can be bold, italic, or ~~strikethrough~~. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. Vape migas chillwave sriracha poutine try-hard distillery. Tattooed shabby chic small batch, pabst art party heirloom letterpress air plant pop-up. Sustainable chia skateboard art party banjo cardigan normcore affogato vexillologist quinoa meggings man bun master cleanse shoreditch readymade. Yuccie prism four dollar toast tbh cardigan iPhone, tumblr listicle live-edge VHS. Pug lyft normcore hot chicken biodiesel, actually keffiyeh thundercats photo booth pour-over twee fam food truck microdosing banh mi. Vice activated charcoal raclette unicorn live-edge post-ironic. Heirloom vexillologist coloring book, beard deep v letterpress echo park humblebrag tilde.

Mon, 01 Jan 0001 00:00:00 +0000

Consuming LabBench HDF5 Files from MATLAB

This guide explains how MATLAB users should read and interpret HDF5 files generated by LabBench using the PureHDF-based exporter.

The layout is intentionally simple, deterministic, and compatible with MATLAB’s built-in h5read, h5info, and array handling.

1. Opening a LabBench HDF5 file

In MATLAB, HDF5 files are accessed using h5info and h5read.

info = h5info('experiment.h5');

All data lives under a single top-level group named after the root object:

Mon, 01 Jan 0001 00:00:00 +0000

Consuming LabBench HDF5 Files from Python

This guide explains how Python users should read and interpret HDF5 files generated by LabBench.

The layout is intentionally simple, deterministic, and compatible with h5py, NumPy, Matlab, and R.

1. Opening a LabBench HDF5 file

import h5py

f = h5py.File("experiment.h5", "r")

All data lives under a single top-level group named after the root object:

/root

So typically:

root = f["root"]

2. Scalars (DataNumber, DataBoolean, DataString)

LabBench scalars are stored as datasets.

Search Results

Mon, 01 Jan 0001 00:00:00 +0000

LabBench on LabBench, Version 6.0

LabBench I/O

Stimulus Response

System

Logging

LabBench CPAR+

Temporal Summation

Arbitrary Temporal Summation

Static Temporal Summation

Conditioned Pain Modulation

LabBench SERVER

LabBench Device Server

LabBench SOUND

Participant validation

Researchers

LabBench JOYSTICK

Stimulus Rating

Conditioned Pain Modulation Rating

Devices

Adding devices

Image Canvas

LabBench I/O

LabBench DISPLAY

Languages and Localization

Protocol properties

Re-run policy

Sessions

Button

Properties

Methods

Button identifiers

Cold Pressor

Development tools

Image Display

Properties

Methods

Typical usage example

Notes / gotchas

Image Engine

Installation

Download installer

Installation

License and installation path

Interval Scale

Properties

Methods

Typical usage example

Notes / gotchas

Joystick

Properties

Methods

JoystickPosition

Properties

Typical usage example

Notes / gotchas

Keyboard

Keyboard Toolkit

LabBench CPAR+

Manual Threshold Estimation

Ordinal Scale

Properties

Methods

Category (IAnchor)

Persistent variables

Pressure Algometer

String Literals

Outlet

Channel

Criterion

Properties

Methods

Typical usage

Pressure Channel (IPressureChannel)

Psychophysics

Properties

Methods

Typical usage example

Psi Method Creator (PsiMethodCreator)

Description

Questionnaire

Category (`IAnchor`)

Pressure Channel (`IPressureChannel`)

Psi Method Creator (`PsiMethodCreator`)

Function: `Create()`

Trigger source (`startTrigger`)

Combined Stimulus (`CombinedValueStimulus`)

Trigger Sequence (`TriggerSequence`)

Waveform (`Waveform`)