reaction time logged between visual target and the key press

[ytgu]

Hi Ting,

For my study, participants first listen to an audio sentence, at the offset of the sentence,  a visual target will appear on the screen, participants need to press a key to indicate if the visual target and the final word of the heard audio sentence is a match or mismatch.

When I looked at the data, I found that the actual RTs should equal to "trial_duration" minus the length of the audio file but not the values in the column "response_rt". Is there a way to directly log the actual RTs that I want onto the FF results spreadsheet? 

Thank you!

Yuting

[Ting]

Hi Yuting - do you mean the reported RT isn't trial_duration - the length of the audio file? Not even approximately? It will never be exactly the same as there are measurement errors (on the millisecond level) and the buffering time involved.

I'm also not quite sure of what you mean by "actual RTs". Can you elaborate a bit? Thanks!

[ytgu]

Hi Yuting - do you mean the reported RT isn't trial_duration - the length of the audio file? Not even approximately? It will never be exactly the same as there are measurement errors (on the millisecond level) and the buffering time involved.

I'm also not quite sure of what you mean by "actual RTs". Can you elaborate a bit? Thanks!

Hi Ting, 

No, the reported RT isn't trial_duration - the length of the audio file, not even approximately (at least for most of the trials). 

What I meant by "actual RTs" is just the trial_duration - the length of the audio file  but maybe it's due to the measurement errors plus the buffering time? As defined by FF grammar book, the rt logged for key press responses is the duration between two key presses, but what we want is the duration between the visual target and the key press. 

Let me know if this makes sense to you!

Thank you,
Yuting

[Ting]

Oh so are you using the keypress response? Gotcha. Can you paste the definition of your audio stimulus here? We want to make sure that you are using barrier properly (which should be the default).

In addition to that, I think the documentation may be partially incorrect - the RT of each keypress is always relative to the onset of the entire keypress response. For example, if you have two RT readouts on a single trial, the second RT readout would be cumulative, representing the duration between the onset of the response and the second key press.

We'll make a decision on whether we'll revise the documentation or fix the code. Apologies for the inconsistency here.

[ytgu]

Oh so are you using the keypress response? Gotcha. Can you paste the definition of your audio stimulus here? We want to make sure that you are using barrier properly (which should be the default).

In addition to that, I think the documentation may be partially incorrect - the RT of each keypress is always relative to the onset of the entire keypress response. For example, if you have two RT readouts on a single trial, the second RT readout would be cumulative, representing the duration between the onset of the response and the second key press.

We'll make a decision on whether we'll revise the documentation or fix the code. Apologies for the inconsistency here.

Sure! Here's the definition: {
  "type": "audio",
  "content": "c_p_1_Set_5_S7_The_shirts_are_hanging_in_the_closet.wav",
  "barrier": false,
  "delay": 0,
  "visible": false
}

Thanks for looking into this!

[Ting]

Hi Yuting - the case is simple. Don't use "barrier": false. Just delete it. By setting barrier to false for the audio stimulus, you are telling findingfive to load all responses at trial onset. And FindingFive faithfully did that.

[ytgu]

Hi Yuting - the case is simple. Don't use "barrier": false. Just delete it. By setting barrier to false for the audio stimulus, you are telling findingfive to load all responses at trial onset. And FindingFive faithfully did that.

Oh I see, thank you!!