Millisecond Forums

Sound stimulus obscuring subject response

https://forums.millisecond.com/Topic15705.aspx

By nicky6056 - 3/7/2015

Hi, I'm trying to program an experiment where participants have to respond as to the case of a letter (upper case = up arrow (200), lower case = down arrow (208)). On certain trials this will be followed by either a noise blast (.wav) or a stimulus through the parallel port system. 

The normal trials are structured like this: 

<trial green_upper_s>
/stimulustimes = [0= upper_text_green; 400 =whiterectangle]
/trialduration = 1700
/validresponse = (200, 208)
/correctresponse = (200)
</trial>

And these seem to work fine, where regardless of when the subject responds the trial runs for 1.7 seconds, and if they press 'up' there is a 1 in the 'correct' column, and a 200 in the 'response'  column. 

However, when I try to add in the sound: 
<trial green_upper_s>
/stimulustimes = [0= upper_text_green; 400 =whiterectangle; 1400 = noise]
/trialduration = 1700
/validresponse = (200, 208)
/correctresponse = (200)
</trial>

Where the 'noise' stimulus is defined by: 
<sound noise>
/ items = ("beep-14.wav")
</sound>

The trials appear to be running correctly, but in the data file there is just a 0 for response and 0 for correct, no matter how quickly/ slowly I press the response. 

Anyone have any ideas? Thanks! 
By Dave - 3/7/2015

By default Inquisit will only start listening for responses once all stimuli specified in /stimulustimes or -frames have been presented. I.e. with

/stimulustimes = [0= upper_text_green; 400 =whiterectangle; 1400 = noise]
/trialduration = 1700

Inquisit will start accepting responses at 1400 ms into the trial (and there'll be approx. 300 ms in which to submit the response).

To have Inquisit accept responses earlier, specify the trial's /beginresponsetime attribute. You may also need to specify a proper /responseinterrupt setting.

By nicky6056 - 4/15/2015

Hi Dave, 
Thanks for your response. The beginresponsetime fixed the data recording problem, and the responseinterrupt = trial feature has stopped the trial from ending before the noise blast can be displayed. However, for some reason this same attribute is not preventing the electric shock stimulus from being skipped. I'm not sure why this trial: 
<trial green_lower_noise_c>
/stimulustimes = [0= noisecomment; 1=lower_text_green; 400 =whiterectangle; 1400 = noise]
/beginresponsetime = 0
/responseinterrupt= trial
/timeout = 1700
/validresponse = (34, 19)
/correctresponse = (19)
</trial>

Whereas this trial: 
<trial red_lower_shock_c>
/stimulustimes = [0= shockcomment; 1= lower_text_red; 400 =whiterectangle; 1400 = shock]
/beginresponsetime = 0
/responseinterrupt= trial
/timeout = 1700
/validresponse = (34, 19)
/correctresponse = (19)
</trial>

where 'shock' is: 
<port shock>
/ port = lpt1
/ subport = data
/ items = ("10000000")
</port>

Results in a trial where if the participant presses an up or down in the middle part of the trial, the electric shock will not be sent (on all other trials it's fine so it's not a problem with the ports). I was thinking of trying a hack where I present a white letter for .05 of a second at the end of the trial or something similar so that inquisit might run the trial the whole way through, but is there an easier way? 
By Dave - 4/15/2015

The port stimulus isn't skipped. It's simply too short for your equipment to pick it up. Suppose a response occurs at, say, 500ms into the trial. The trial would then go on to "display" shock at 1400ms and *immediately* terminate after that. Try adding another stimulus some time after shock to make sure the signal remains raised long enough to be registered by your equipment.