Making customizable scenarios

Today, I want to blog about a new feature introduced in the 0.9.0 release : the ability to use configuration token in all the settings of a scenario. This post is kind of an update or enhancement of the Setting up an experiment environment one… In case you don’t remind this post, I suggest that you go back to it first… 😉

Done ?

Already ?

Right so I now assume the configuration manager has no secret for you and that all your scenarios are using configuration tokens such as e.g. $core{date} and $core{time} to preserve your signal records.

So let’s move on this new feature now. Experienced users have probably noticed that the settings dialogs of the designer have changed in the 0.9.0 release. For instance, here is a snapshot of the configuration dialog of the Stimulation Based Epoching box in the 0.8.0 release :

Stimulation Based Epoching configuration dialog as displayed in the 0.8.0 release.

and here is a snapshot of the configuration dialog of the Stimulation Based Epoching box in the 0.9.0 release :

Stimulation Based Epoching configuration dialog as displayed in the 0.9.0 release.

The thing that makes the difference here is that we replaced all the GTK widgets dedicated to specific types with only text entries. We tried to decorate those text entries so that they look like a familiar GTK widget. For instance, for integer or float values, we added those up and down arrows to change the value in a scrolling way. But what is interesting here is that you can enter an actual string in each of those text entries. Why would you use a string in a setting that expects an integer or an enumeration entry ? Just because if this string is expanded by the configuration manager, then you can use a configuration token ! And if you can use a configuration token, then you can customize the runtime session with your own configuration file without any need to modify the scenario ! So for this reason, the player part of the kernel now takes care of expanding every type of setting (not only the filenames) when a box requires them. This update has been totally transparent for every existing boxes.

Another interesting use of this new feature is to modify a common parameter of several boxes in a single step. Let’s take the example of the P300 speller sample scenarios. The online or the replay scenario for instance is using 12 Stimulation Based Epoching boxes in order to select the evoked brain response to the flash that just appeared. The offset and the duration of the selected signal are common parameters : 0ms for the offset and 600ms for the duration of the epoch. The third and last parameter of this box is the stimulation that causes the epoching : OVTK_StimulationId_Label_01 to OVTK_StimulationId_Label_0B. This parameter is different for each box. Now suppose I want to test several different durations and see if the system performs better. Then I have to replace the 600ms duration with say 800ms for each of the 12 boxes individually. The per-box configuration files, also known as settings override, won’t help here. Indeed, the stimulation to use is different for each box. So putting a configuration token here will definitely save some time !

What’s next ? Well, I think that possibility to play with configuration tokens at the scenario-level would provide better productivity. This supposes that the scenario is able to embed a few configuration tokens and that those tokens can be edited in the designer, maybe in a new panel on the right side. Of course, the configuration manager that is created for each player will have to handle those tokens on request. This will be done progressively… :)

Have fun hacking your scenarios !

Comments are closed.