Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Trouble determining when Logger starts counting for Reaction Times

edited April 2018 in OpenSesame

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!

Comments

  • 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

  • edited April 2018

    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!

  • 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

  • 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].

  • 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

    Buy Me A Coffee

Sign In or Register to comment.

agen judi bola , sportbook, casino, togel, number game, singapore, tangkas, basket, slot, poker, dominoqq, agen bola. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 50.000 ,- bonus cashback hingga 10% , diskon togel hingga 66% bisa bermain di android dan IOS kapanpun dan dimana pun. poker , bandarq , aduq, domino qq , dominobet. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 10.000 ,- bonus turnover 0.5% dan bonus referral 20%. Bonus - bonus yang dihadirkan bisa terbilang cukup tinggi dan memuaskan, anda hanya perlu memasang pada situs yang memberikan bursa pasaran terbaik yaitu http://45.77.173.118/ Bola168. Situs penyedia segala jenis permainan poker online kini semakin banyak ditemukan di Internet, salah satunya TahunQQ merupakan situs Agen Judi Domino66 Dan BandarQ Terpercaya yang mampu memberikan banyak provit bagi bettornya. Permainan Yang Di Sediakan Dewi365 Juga sangat banyak Dan menarik dan Peluang untuk memenangkan Taruhan Judi online ini juga sangat mudah . Mainkan Segera Taruhan Sportbook anda bersama Agen Judi Bola Bersama Dewi365 Kemenangan Anda Berapa pun akan Terbayarkan. Tersedia 9 macam permainan seru yang bisa kamu mainkan hanya di dalam 1 ID saja. Permainan seru yang tersedia seperti Poker, Domino QQ Dan juga BandarQ Online. Semuanya tersedia lengkap hanya di ABGQQ. Situs ABGQQ sangat mudah dimenangkan, kamu juga akan mendapatkan mega bonus dan setiap pemain berhak mendapatkan cashback mingguan. ABGQQ juga telah diakui sebagai Bandar Domino Online yang menjamin sistem FAIR PLAY disetiap permainan yang bisa dimainkan dengan deposit minimal hanya Rp.25.000. DEWI365 adalah Bandar Judi Bola Terpercaya & resmi dan terpercaya di indonesia. Situs judi bola ini menyediakan fasilitas bagi anda untuk dapat bermain memainkan permainan judi bola. Didalam situs ini memiliki berbagai permainan taruhan bola terlengkap seperti Sbobet, yang membuat DEWI365 menjadi situs judi bola terbaik dan terpercaya di Indonesia. Tentunya sebagai situs yang bertugas sebagai Bandar Poker Online pastinya akan berusaha untuk menjaga semua informasi dan keamanan yang terdapat di POKERQQ13. Kotakqq adalah situs Judi Poker Online Terpercayayang menyediakan 9 jenis permainan sakong online, dominoqq, domino99, bandarq, bandar ceme, aduq, poker online, bandar poker, balak66, perang baccarat, dan capsa susun. Dengan minimal deposit withdraw 15.000 Anda sudah bisa memainkan semua permaina pkv games di situs kami. Jackpot besar,Win rate tinggi, Fair play, PKV Games