[open] Two same stimuli-pairs: difference in velocity of presentation
This is a audio-visual multisensory integration experiment. In particular here I am creating a two-interval, forced-choice task.
There are two stimuli presentations: one (always) synchronous and one asynchronous (defined by different SOA as reported here: http://www.cogsci.nl/forum/index.php?p=/discussion/849/solved-soa-stimulus-onset-asynchronies#Item_6).
I created my experiment as follows:
Block
sequence (at the first step, the program imports the sampler and the sound).
sequence 1: first presentation
interval (a schetchpad with a random duration)
sequence 2: second presentation
answers
The sequence 1 consists of this inline script (different SOA between visual and auditory stimuli presentation)
SOA1 = exp.get("soa1_var") # change 'soa_var' to the variable you use for the SOA!
if SOA1 == -10 or SOA1 == -30 or SOA1 == -50 or SOA1 == -80 or SOA1 == -100 or SOA1 == -150 or SOA1 == -200 or SOA1 == -250 or SOA1 == -300:
exp.beep.play()
self.sleep(abs(SOA1))
exp.circle.show()
elif SOA1 == 10 or SOA1 == 30 or SOA1 == 50 or SOA1 == 80 or SOA1 == 100 or SOA1 == 150 or SOA1 == 200 or SOA1 == 250 or SOA1 == 300:
exp.circle.show()
self.sleep(abs(SOA1))
exp.beep.play()
else:
exp.beep.play()
exp.circle.show()
This is the inline script for sequence 2
SOA2 = exp.get("soa2_var") # change 'soa_var' to the variable you use for the SOA!
if SOA2 == -10 or SOA2 == -30 or SOA2 == -50 or SOA2 == -80 or SOA2 == -100 or SOA2 == -150 or SOA2 == -200 or SOA2 == -250 or SOA2 == -300:
exp.beep.play()
self.sleep(abs(SOA2))
exp.circle.show()
elif SOA2 == 10 or SOA2 == 30 or SOA2 == 50 or SOA2 == 80 or SOA2 == 100 or SOA2 == 150 or SOA2 == 200 or SOA2 == 250 or SOA2 == 300:
exp.circle.show()
self.sleep(abs(SOA2))
exp.beep.play()
else:
exp.beep.play()
exp.circle.show()
My problem is that in the second block the visual stimulus doesn’t appear or it is faster then in the first presentation (i.e. in the second presentation the circle disappears faster then in the first one). This difference is obvious if you set the same SOA for the first and the second sequences. Any idea about it?
Thank you,
Federica
Comments
Hi Federica,
What kind of item is placed directly after the inline_scripts? If it is not a sketchpad (or feedback or any other visual item), the visual stimulus will remain on-screen for longer than the time you might have expected it to do.
If you're unsure, could you perhaps post a screenshot of your experiment's overview?
Thanks!
Edwin
And here the screenshot of my experiment's overview, where:
[pair 1]
import: import the libraries that we will need; # create the sound, using my file and create the display with a central circle;
SOA1: as I previously described.
Schetchpad with a duration of 0.
then
and after the [pair 2] with the same logic of the [part 1].
I’m just wondering if there would be some problem in term of pc velocity during the trial execution; perhaps there would need to use some inline script to set to pc to update/recover time throughout the passage from one trial to the next one: what do you think? what kind of command would be?
Thank you very much,
Federica
There's nothing wrong with your PC, just with your experiment's logic.
1) You're importing stuff twice, and in different inline_script items. Please note that the thread you link to in your opening post, speaks of placing the imports (and further setup, defining some sounds and canvases) in an inline_script at the start of your experiment, rather than somewhere within the trial sequence.
2) Why is there an extra sequence in the middle of your trial sequence? Wouldn't it make more sense to simply add the items within that sequence to the general trial sequence? This might lead to added loading times, so if you don't have a good reason to do so, please consider omitting the nested sequence.
If these two improvement don't lead to better timing, please do report back!
Good luck!
Dear Edwin,
I followed your precious suggestions (thank's!!!): here the screenshot of the actual experiment's overview.
However, the problem is still there: the second pair appears to be faster the the first one.
That's curious! Could you post the code of the experiment online, or email me the experiment? We'll keep the discussion on the forum, but this would be the easiest way of checking your entire experiment (since, at the moment, the problem could be in at least four different items).
Turns out the solution is surprisingly simple! The timing of the second stimulus isn't very different from the first, actually. The problem you face lies in the fact that when SOA < 1, the beep is presented first and the dot is displayed second, but there is no pause after the presentation of the dot. This means that the sketchpads placed directly after the inline_scripts will immediately change the screen.
So after the inline_script SOA1 a fixation cross will overwrite the dot, and after the inline_script SOA2 a question mark will overwrite the dot. The first dot seems to linger longer than the second one, but I think this is due to the very weak masking of the dot stimulus by the fixation cross as compared to the question mark.
If you want your dot stimulus to appear slightly longer on screen, you will have to introduce some kind of delay somewhere. You could do so by adding an advanced_delay item directly after the inline_scripts SOA1 and SOA2, or by using the
self.sleep
function at the end of your inline script.Do note, however, that when SOA > 0, the circle will remain on screen for SOA + the added delay (so slightly longer than in your other conditions).