• French

Package manager for MindRun

License required

A specific license is required to manage MindRun packages from MindDev Research.

The package manager for MindRun allows you to manage (create/modify) your own test packages. MindRun cannot function without these packages. The aim is to provide a database of protocol entries that MindRun can execute.

Since everything in MindRun is automated, some preparatory work needs to be done in order to exploit its protocols properly.

The MindRun Package Manager in MindDev Research.

The vertical toolbar gives access to all the useful tools for managing the open package:

• Load a package
• Save open package (under same or different name)
• Check database
• Create a zip file of protocols
• Create encrypted package

Check the database

Always check the database before publishing your package. MindDev Reasearch will complete any information not shown in the interface and automatically manage internal identifiers. This action is mandatory when publishing the package.

Creating a package zip file

Creating a package zip file enables you to create a zip archive containing all the package protocols and their dependencies. In the event of distribution, this zip file must also be supplied.

Encrypted package creation

Creating an encrypted package enables you to create a file in prdb format, which is a copy of the xml package file, with the difference that the file can no longer be modified because it is encrypted. This option ensures that the package is not modified.

In addition to these generic tools, MindDev also includes familiar tree representation tools:

In addition to these generic tools, MindDev also includes tools that are familiar from tree representations:

• Add a new node
• Get help
• Move a node up/down in its parent list
• Copy/paste

This handler behaves in the same way as other tree-based handlers. The root node is the package database. It is possible to add, delete and modify a database entry.

Protocol entry

The package contains nothing more than a protocol list. This list can be extended at will. A protocol, in the sense of the package manager, is a little different from the Protocol as we know it in MindDev. This is a protocol reference. In effect, the package is a database that contains protocol references, without ever storing their contents.

A protocol entry in the MindRun Package Manager.

Protocol reference

In the Lite Package Manager, a package contains no protocols, just references to the protocol files themselves.

Protocol reference name and description

The name of the protocol reference will appear in MindRun, as will the description.

When adding a protocol entry, the following options are available:

• Name of the test set (which groups protocols within the same category)
• Name of the protocol file (to be executed when a run is launched)
• Name of the filtered protocol file (containing scoring and filters)
• Protocol help url (optional)
• Information about using a VR headset
• Information on the use of a peripheral device

Dynamic properties

In MindRun, by default, it is not possible to modify the contents of a protocol. This poses certain problems, especially when addressing certain devices directly (USB, Bluetooth, IP, etc.). To solve this problem, each protocol entry has a list of dynamic properties.

A dynamic property in the MindRun Package Manager.

By default, and in many cases, the protocol entry does not contain dynamic properties.

Adding a dynamic property enables its configuration:

• the object name subject to parameter modification
• Property name
• The default value
• The property name displayed in MindRun

Using the object name

In MindDev, to be sure of selecting the right object, we use its internal identifier. Using an object name reference to select the object selects all objects with that name, making it possible to dynamically modify several objects at the same time.

Naturally, the protocol must contain one or more objects with the name given in the dynamic property. Similarly, the property name must correspond to a property of the linked object. As for the value, it must conform in terms of type (a numerical value must not contain letters).

dynamic multi-property

In certain situations, it may be useful to control several properties of different nodes with a single dynamic property. Rather than creating several dynamic properties, it is possible to create Dynamic Multi-Properties. In this case, one value will control several properties which do not have the same name.

Specific attribute for reading dynamic properties

By default, a protocol has no way of reading MindRun's dynamic properties. It is not designed to do so. To tell a protocol that it must read the dynamic properties database, we need to add a specific attribute on the protocol entity of the protocol to be executed.

The dynamic property management attribute in a protocol.

The attribute is added on the protocol entity only, it's the Dynamic Property Reader attribute. Once added, this attribute will read the dynamic property database, find the corresponding protocol entry and assign the dynamic property set on all affected objects.

Entities and attributes dedicated to the Web server

Communication with MindRun's dedicated Web server is not natural in protocol design. In fact, one protocol does not support commands sent by MindRun's Web server.

Web server functionalities allow you to :

• Stop the current protocol (Stop Signal)
• Send a trigger in the form of a numerical value (Trigger).

For these two Web server functionalities, there is either an attribute or an entity enabling them to be taken into account:

• The Lite Stop Signal Listener protocol attribute
• The Memory Mapper (Float Value) entity for registering triggers.

The `Lite Stop Signal Listener` protocol attribute.

The trigger registration entity.

Displaying Full Results

MindRun offers a feature for viewing so-called "full" results. The purpose of this feature is to allow users to view and export trial data from MindRun. By default, MindRun provides a score display per experiment and an Excel-style entry point graph for each trial. Internal trial data, although present, is not displayed by default.

Indeed, displaying all results in full would cause an overload of information, especially since not all data necessarily needs to be shown. It is possible to allow the display of selected intra-trial data, predetermined in advance (this configuration cannot be modified by the MindRun user).

This setup is done within the analysis protocol in MindDev. As explained in the section on protocol entries for MindRun tools, a MindRun protocol entry contains an execution protocol and a protocol used for automatic analysis. The analysis protocol can be modified to allow the display of specific intra-trial data.

To do this, you must perform a standard analysis of the protocol. For each intra-trial data item that should be viewable in MindRun, add the MindRun View Filter to it.

MindRun View Filter.

Full Display in MindRun

It is entirely possible to have multiple MindRun View Filter entries within a single trial. This will make mult