Hi,
I’m trying to build an experiment in SuperLab 4.0. My experiment needs to be 6 seconds of fixation on a + sign followed by a stimulus of a flashing + sign at 2Hz for 30 seconds. The subject should then be presented with a non-flashing + sign for 30 seconds, then flashing, then non-flashing for a total of three epochs. The confounding variable is that I would like auditory instructions to preceed each change in flashing/non-flashing state.
For example, I have 2 audio files, one says “start tapping your finger” and the other says “stop tapping your finger”. Each have a length of 2 seconds. So I would like the software to present the fixation + for 4 seconds silently, then begin playing the “start tapping” audio while the + is presented for another 2 seconds. I would then like the + sign to flash for 28 seconds silently followed by 2 seconds in which the “stop tapping” sound is played while a flashing cross is presented.
My solution so far has been to break each visual “state” up into 2 parts, a silent part and a part with audio. For the fixation, I have created a “Show the text below” event with a + sign for 4 seconds, followed by an audio event with a maximum length of 0 ms, but the “Allow sound to continue playing beyond trial end”. The next event is another 2 seconds of the solid + sign.
To create the flashing + sign, I’ve created 2 lists of “+” or " " text, repeated a total of 60 times. I give each event a duration of 250 ms, i.e. 2 Hz. The first list has 52 entries, I then play the sound as above (duration of 0 ms, etc) and start another 2 second trial of the flashing “+” sign. I’ve tried this with both “Reset RT Timer” checked and unchecked.
The first trial (Silent solid + sign, audio, solid + sign) works great. The second state however results in my audio file being played in a very choppy manner at the beginning of the trial, not the end. Also, the flashing + sign is very irregular. My conclusion is that all three events are playing at once. Could someone on the list help me?
I know this is fairly complicated, so let me know if I need to upload the experiment.
Are you running on a Mac or Windows? Do you have a single processor system or dual-processor/multi-core system? To figure out the audio issue, I’ll need to know a bit about your system (and probably see the experiment itself).
An alternate approach that can help with the timing of the alternating “+” sign: Use the RSVP event type (Rapid Serial Visual Presentation). Enter the following as the text:
+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\+\
(or as many as you need). Set the event to end after 250ms (maybe a little less).
SuperLab focuses on the timing of individual trials and does its work between trials. Therefore, in having each state of the “+” be a separate trial, SuperLab is doing much more work than necessary. The RSVP event will effectively combine all of that into one trial, improving your timing. Note that the 250ms is in addition to the time it takes to present the actual event. On my machines, this ranges from about 10ms to 20ms, so you may want to set the event to be 230ms instead.
Yet another approach would be to not give a time on the events themselves but set the trials (in your original stim-list-based approach) to be presented every 250ms. This will be the most consistent approach if you are looking for exactly 2Hz.
My system has a Windows XP running on a single core 32 bit processor.
The RSVP system seems to have solved the problem (I need to investigate the presentation time issue). The audio, however, fails to terminate after playing and plays the last about 1/10th of a second over and over. I’ve made this less of a problem by adding about 1/4 second of silence to the end of my audio files, but I’m sure there is a better solution.
I’ve tested this on two different systems with identical results.
I’ve attached an example experiment with its associated audio files.
I haven’t been able to duplicate this issue on either my Mac or my PC. Do you have the latest version of DirectX 9 installed?
I did find and fix an issue related to cleaning up after an audio event finishes playing, but I don’t think this is any way related to the issue you’re hearing.