Trouble determining when Logger starts counting for Reaction Times

jhgscott

I've run a couple phoneme detection/phoneme monitoring experiments using the expyriment back end in Open Sesame. Basically, a one-word audio stimulus is played, and respondents press Space as quickly as possible when they hear the phoneme listening target in the word (say, [t]). Reaction Time is a crucial dependent variable.

For each stimulus, I've measured when the target sound begins in the audio file. But when I compare that with the response_time variable recorded by the Logger, I get an unusually high proportion of negative values for the difference, which seems to indicate that they responded before hearing the listening target sound much more frequently than random variation would suggest is likely.

There are various other possibilities for why a response could be recorded before the specific sound in the stimulus came up, such as very slow response to previous trials, anticipating a sound that hasn't come up yet, etc. But I need to determine for certain when the Logger actually starts "listening" for responses to interpret the response_time variable in each trial.

Trial Loops are structured in the following sequence of objects:

• Loop
  • Trials
    • break (sketchpad, duration = 0 ms)
    • End_Break (keyboard response, timeout = infinite)
    • fixation_dot (duration = 500 ms)
    • blank_screen (sketchpad, duration = 0 ms)
    • delay100 (delay = 100 ms, jitter = 0 ms)
    • PlayWord (sampler, duration = sound, o ms stop after/fade in
    • Target_Response (keyboard response, flush pending keypresses, Timeout 700 ms)
    • logger (Logger, automatically detect/log all variables, incl. var. w/ missing values, put quotes around values)
    • delay100 (delay = 100 ms, jitter = 0 ms)

With such a build, is the Logger counting from the start of the trial? From the start of the Sampler playback? From the end of the Sampler playback?

Depending on the answer to this, "negative" response_time values may not be a problem fixed by an easy arithmetical operation, or they might be a serious problem to the data set.

I appreciate any insight I can get into this as I try to analyze these results. Thanks!

sebastiaan

Hi,

The way you've set up things, PlayWord will pause the experiment until the sound is finished, because duration is set to 'sound'. And only then Target_Response will start collecting responses, with the response time being relative to the start of Target_Response (and hence also the end ofPlayWord).

In other words, it's not logically possible to get anticipatory responses with this structure! Which variables are you comparing with each other that brought you to this conclusion?

Cheers!
Sebastiaan

jhgscott

Hi Sebastiaan,

Thanks for looking at this. The only Logger-specific variable involved in my comparison is response_time, which is always positive in the OpenSesame output (max = 700 ms, i.e., timeout). The other variable is one I created and inserted later (I called it targ-on), which is the timing of the target sound's start in the audio file (measured separately in Praat). For example, if the full duration of the audio file is 650 ms, the onset of a final [t] might be at 582 ms, so targ-on might have a value of 582.

Under my earlier assumption that the logger started measuring for response_time at the beginning of the trial, I had created a new variable from the difference, intending to get a Reaction Time (RT) calibrated to where the listening target occurred in each stimulus:

Diff_RT = response_time - targ-on

It seems what happened was that response_time (from the logger) was always 1-700 ms, and targ-on was always positive, based on distance of the listening target from the start of the audio file. Had the logger been counting time from the start of the trial, then subtraction would be necessary to calculate a true Reaction Time to the part of the stimulus respondents were listening for. But as it is, response_time and targ-on have a different relationship, because response_time should be related to the duration of the audio file after the onset of the listening target, not the duration until that onset.

But with the logger only counting time after the playback was finished, then it seems instead I should be comparing response_time with the duration of the portion of the stimulus that remained from the onset of my listening target until the end of the audio file. For example, if my stimulus was the nonce word [baxt], and [t] was the listening target, I should be doing this in 2 steps instead:

(1) calculate
audio file duration - targ-on = remaining audio duration

(2) calculate
Reaction Time = response_time + remaining audio duration

That should get me the "true" Reaction Time for any response made after PlayWord was done, correct?

Fortunately, all my critical trials place the listening target in final position, so the majority should of them should still be measured by the logger, though perhaps with very small positive response_time values.

Do I understand correctly then that, with this build, any keyboard response made during the PlayWord part of the trial would not be recorded by the logger at all? This could affect many of the fillers, in which the listening target was located much earlier in the audio file.

Thanks again for your help!

sebastiaan

Hi,

The response_time is simply the time between the onset of the response item and the moment that a participant presses a key. Because of how you set things up, this means that you're measuring the response time relative to the moment that the sound (PlayWord) finished playing. And because you've enabled 'flush pending keypresses', any responses made during sound playback are discarded. Does that make sense? It's not complicated, but it's probably not what you wanted to do either.

I don't fully understand what you're trying to do, though. Could you explain in a bit more simple terms (and fewer words!) what you want to measure exactly?

Cheers!
Sebastiaan

jhgscott

Hi,

No problem. Here's a briefer explanation, followed by a real example.

What I wanted to do:
The phoneme detection task presents a list of words; participants press a key as fast as possible when they hear a specific target sound--perhaps a [k], [p], or [t]. Certain conditions can induce shifts in processing time; for example, if the sounds of the stimuli violate a phonological expectation, there may be a (mean) 30 ms delay in reaction. The goal is to measure shifts in reaction time between the start of the listening target and the keystroke response.

What I actually did:
Due to my design, response_time only collected responses made after Playback ('flush pending key responses') and only counted time from the end of Playback (due to how I ordered the objects in the trial structure). So my experiment did not measure how many ms duration remained in the Playback between the start of the listening target and the key response.

How you helped:
You helped me understand where the logger started recording. If it had logged responses starting earlier in the trial, it would have different implications for interpreting the data. This means 2 things for me:
1) A small number of early responses (made during Playback) may have no data.
2) I need to manually augment response_time with those remaining post-target durations.

Example from my stimuli:
Stimulus = [baxt] (as Bacht would typically sound in German)
Listening target = [t]
Playback audio file duration = 624 ms
In that file, [t] starts at 456 ms and ends at 618 ms.
The duration of [t] is 162 ms, and the remaining Playback duration is 624 - 456 = 168 ms.

One respondent had a response_time of 176 ms (logger variable).

To get a "true" reaction time for this trial on this stimulus, I need to add 168 ms to reaction_time, deriving an augmented ("true") reaction time of 344 ms.

In the example, [t] is at the end of the audio file. But in some stimuli the listening target has a longer duration, and in fillers (e.g., mittrig), it is placed earlier, so the difference can be as much as 800 ms. Fortunately, my conditions of interest use final position only (like the example), so most crucial responses were recorded and the augmentation of response_time will only vary by the duration of each [t].

eduard

Hi,

Good that everything worked out for you. But just a future reference, it might be handy to set the duration field of the sampler to 0. Like that you will immediately proceed to the response item and wait for a keypress while the sound is still playing. In that scenario you won't miss keypresses if participants respond very quickly and the target is early in the sample. However, you still need to do some math, to get the true response times.

Hope this helps.

Eduard