Multiple Random Images and User Choice

SuperLab SuperLab 4 Support
1

I’m having trouble coding what I thought was a relatively simple experiment. Here is what I’m trying to do:

  • simultaneously display three DIFFERENT random images from either one stimulus list or 3 copies of the same list
  • have the user select one of the images using the keyboard
  • play a sound file
  • then display the chosen image

Where I’m running into problems:

  • I can get the three images to appear simultaneously and order of the images to randomize, but they always appear three of the same kind. I’d like the three images to each be randomized separately, so the combination of 3 is not predicatable
  • how can I have the image displayed at the end be defined by their choice earlier in the trial?

I’d appreciate any help.

  • Alex
2

Hi Alex,

The first hurdle can be overcome by creating three stimulus lists with identical contents except that the contents of the 2nd list will be offset by 1 and the contents of the 3rd list offset by 2. For example, if the list has five pictures as follows:

pict1.jpg
pict2.jpg
pict3.jpg
pict4.jpg
pict5.jpg

then the second list will have

pict5.jpg
pict1.jpg
pict2.jpg
pict3.jpg
pict4.jpg

and the third list will have

pict4.jpg
pict5.jpg
pict1.jpg
pict2.jpg
pict3.jpg

Unfortunately I cannot think of a way to overcome the second hurdle for now because SuperLab allows feedback based on whether the response was correct or incorrect. It should in a future version allow feedback based on which response was provided by the participant regardless of correctness.

Hisham.

3

Thanks for your reply Hisham. Just to be clear, can you confirm that using Superlab I cannot allow the user to select one of three images and then based upon their choice display that image in a larger size.

4

I have a method that will work, but there are limitations. It will only work with three stimuli, and it requires the use of both the key press AND the key release. I’ll put together an example experiment to show the idea.

5

One more limitation… it’s not compatible with stimulus lists.

Here’s how the trial runs:

  1. Present the three stimuli
  2. An arbitrary one of them is the correct response, so a key press on this stimulus is correct.
  3. If correct, present the event that displays this image, and then end the trial (otherwise continue)
  4. An arbitrary one of the remaining two is now the correct response, so a key release on this stimulus is correct.
  5. If correct, present the event that displays this second image, and then end the trial.
  6. If incorrect, there is only one more stimulus that could have been selected. Present it and end the trial.
6

Very bizarre approach

I’ve been pondering the feasability of the following approach to making a Superlab scenario conditional on subject input. It depends on two things: (1) the logfile must be flushed to disk after each entry is added, and (2) only stimuli that are loaded from files in mid-run can be subject to the conditions.

What you do is have a separate program running in the background while the experiment is going on, monitoring the logfile’s last few lines (or as much of it as needed). Depending on the contents of the logfile, certain specific images, sounds, or videos would be copied from files whose names do not appear in the scenario into files whose names do appear. To illustrate, in one simple scenario there might be only one trial, repeated ad infinitum, that always loaded a picture called “thepic.jpg”, read a response which is written into the logfile, and waited for one second. But after each response was written into the logfile, the background program would rewrite “thepic.jpg” with a new image, depending on the reponses to previous ones; on the next trial, it would be the current new image that would be displayed to the subject.

Yes, it’s kind of fragile in that some kind of interlocking would be necessary to prevent races and other oddities, but I think that in an extreme case, as a lost resort, it could work. If there were an option within Superlab to respect file locking by delaying until the lock was removed (or some other kind of simple synchronization strategy), then it would definitely work.

I’m not suggesting or recommending this, but I simply throw it out as one strange possibility.

By the way, there are some other, probably more interesting possibilities, such as real-time remote monitoring of things like error rate and mean RT, that you could do with a line-buffered logfile and a background program.

Greg Shenaut

7

The text that goes into the data file isn’t even built until after the experiment is run, so this approach would take a pretty serious restructuring of SuperLab 4 to be feasible. The (incomplete) verbose log could potentially be flushed after every line, but this doesn’t have the same set of info that the data file has. Neither of these is likely to happen with SuperLab 4.