2008-08-08

An example experimental project

This project, which we call "picolf6" consists of six experiments, four of which use Sensonics odor labels as stimuli. In addition, the counterbalancing and randomization is within each of the two sets of three experiments. Therefore, this was done by scripts rather than within Superlab.

One discovery we made about Superlab in the course of setting up picolf6 was that any time that a file system path is stored within Superlab, all symbolic links within the path are expanded and the path converted to an absolute path. This complicated several aspects of the process.

There are three types of stimuli used: pictures (stored as .jpg files), words (stored as .png files) and ticket numbers (stored as .png files). If you will refer to my recent blog entry on the sl4am hierarchy, you will see the layout we used here. Under the project directory, there is a Shared directory containing all of the .sl4 Superlab scenarios, and folders for all stimuli. The general idea is that the folder for each experiment (with subjects and groups) will have a link back to the scenario for that experiment in Shared, plus a "stim" folder containing links back to specific stimulus files within Shared.

The odor labels we used were mounted on standard 1"x2" event tickets and torn off one at a time to be "scratched and sniffed" and given to the subject. So, one of the things required is for there to be an inobtrusive ticket number displayed on the screen at the beginning of each trial. In superlab, the only way to do that is to make a graphic with the numbers in the corners and then specify that superlab scale it to fill the screen. We used the least significant digits of the tickets for this, so experiment 1 used tickets 1-30, exp 4 31-42, exp 5 43-54, and exp 6 55-66. Since this was always the same for all subjects, we set up folders in Shared named ticket[1456] and stored the .png files with the images there, named, e.g., 23.png.

One thing we learned the hard way was that it is best to set Superlab up so that the scenario is in a file hierarchy identical to where the experiment will be run. So for example, we simply specified /Users/.../Shared/ticket1 and Superlab could use the same relative path at runtime and find the stimulus folders.

The other stimuli were more complicated, because they had to be different for each subject. Superlab always accesses stimulus list folder contents in alphabetical order, so while setting up the experiment, we set up dummy folders containing files with names like w/img34.png (for word image event #34). Later, when setting up the hierarchy, we put links with those names to image files in Shared. So if for example on trial #34, a certain subject needs to see the word "alligator", stim/w/img34.png would be a link to ../../../../../Shared/words/alligator.png (for example).

Now, Superlab doesn't print the name of the file in a stimulus list folder, only its sequence number. So in order to figure out which stimuli were presented to a give subject without going back to the setup data, we inserted a dummy text event into each trial. These events were simply numbered like "@=1-34=@" for experiment 1, trial 34. As part of the setup sequence, we created a sed script that we placed into each experiment folder that translates that dummy code into a condition code for that trial, for example "alligator:old". This allows the actual stimuli that were used to be determined.

We also placed a link to a superlab scenario file in Shared into each experiment subfolder. However, we were not able to use symbolic links for this, since superlab then assumes that the scenario file is actually in the Shared folder and all of the subject-specific links fail to work. As a work-around, we just used hard links for it, since it is a file rather than a directory (file system rules disallow hard-linking to directories).

Here is a tar archive (tgz) of the Korn shell scripts I used to set this experiment up. Note that you also will need to install some packages to generate the graphics versions of the textual stimuli. I also didn't include the picture stimuli we used.

2008-08-03

Multiple superlab stimulus folders

Apparently when you set up an experiment in Superlab that uses external stimulus files or folders, it saves two pointers to the files: the absolute path at the time the file or folder was specified, and the file or folder relative to the scenario file when it was saved. In fact, it appears that sometimeis if you use "save as" within superlab to save a scenario, it recomputes the relative address(es) using the new scenario location. Therefore, as long as the relative path points to folders and/or files that exist, and that the absolute path does NOT exist, things will work. However, this latter approach will not always work

However, if the absolute path is valid, then those files will be used instead of the local relative path, and the wrong stimuli will be presented. What is needed is some way to relocate the scenario file, relative to a certain version of the stimulus files.

Say for example you have 25 subject folders named 01-25, and they are all "sister" folders, that is, subfolders of the same superordinate folder. You might think that if you set up the scenario and stored the scenario in subject 01's folder, you could then copy the scenario into each of the others and use their stimulus set-up. But since the absolute address of subject 01's stimuli would still exist, I strongly suspect that they would be used instead of the relative address. What is needed is some way to relocate the paths in the scenario file so that they point to the new location.

If superlab can't find the stimuli, it asks the experimenter where they are. This could cause some fairly minor problems, but the larger issue is when it does find them, in the wrong place.

It turns out that it is possible simply to overlay the absolute paths (or as many of them as you want to relativize) with a sequence of X's of the same length, using some method such as a binary editor like bbe(1). Superlab is quite content to use the relative address. Note that if you should happen to save the scenario, new absolute addresses will be written in there.

It would be better if there were some way to identify the absolute addresses automatically, but since they can be located almost anywhere, that's a bit tricky. There are some other paths in there, such as the default logfile location. Maybe the best way is simply to specify them as part of the setup, since they will be known then, and do the overlay as part of building the project.

UPDATE

One very important lesson: take the time to do all development of superlab scenarios in a directory hierarchy that matches how it will eventually be installed. This is a little less convenient in the beginning, but pays off hugely later on.

About Me

My photo
Ignavis semper feriƦ sunt.