Adding a 'too fast!' contigency to a coroutine for early responses

LJGS · June 2017

Hi, I am working on the project below:

https://www.dropbox.com/s/a8fmln1gvmjbl8e/stop-signal-task-coroutines-attempt2.osexp?dl=0

I have run into an issue I cannot figure out. I have a simple RT component to my experiment, and so I need some way to prevent early guesses from participants. What I want is for them to get a 'too fast!' warning if they do respond early, rather than proceeding with the trial. What I am defining as early is any time during 'blank' in simpleRT_sequence, and any time in the first 100 milliseconds of the subsequent coroutines. Any response later than 100ms in the coroutines I would not assume to be an anticipatory guess.

Hoping somebody could help?

Thanks very much.

sebastiaan · June 2017

Hi,

First things first! What kind of behavior do you want exactly? What does it mean to 'not proceed with the trial'? Surely a trial is over and done for after an anticipatory response, so I assume you want to repeat a trial when this happens. But do you want to repeat it immediately, or at some random point along with the remaining trials (something that the repeat_cycle item does)?

Cheers,
Sebastiaan

LJGS · June 2017

Hi, thanks very much for your reply. I appreciate the support on what I think is a very niche requirement of mine.

I think what you suggested with the repeat_cycle item sounds great- the trial ending with some type of feedback indicating they were too fast, but then the trial is repeated later in the block at some random point. I guess the question is, how can I make that fit with my current setup, such that the repeat_cycle item will be triggered either if a response is made on the blank, or within 100ms of the coroutine?

sebastiaan · June 2017

You could use a run-if statement that runs the repeat_cycle item only if a response time of less than 100 ms was recorded: [response_time] < 100. This should come after the coroutines, in the simpleRT_sequence. I think that should do the trick?

LJGS · June 2017

Cheers, that works perfectly. They now would not be able to respond within the first 100ms which should stop the majority of pre-empting. That was my original question, but I wonder is it possible to somehow also enable this for the blank screen proceeding the coroutines, as well? To make sure I totally catch any early responding. Something like if any key press on that screen, jump to the feedback and repeat cycle. I tried adding a keyboard response up there as well, but I think I botched it, things seemed to go haywire.

sebastiaan · June 2017

The keyboard_response has a 'Flush pending keypresses' option. If you disable that, old key presses won't be flushed, but will result in a 0 ms response time. So that would accomplish what you want, right?

Whether this is a good idea, I'm not sure. It's easy for participants to accidentally press a key every now and then, and you don't want to unnecessarily punish them for that.

LJGS · June 2017

Yes, that pretty much does what I want, cheers.

Hmmm... I agree with you that I don't want to punish really early key presses (i.e., on the fixation dot). But I do want to punish keypresses any time from the blank onwards. Is there a way to effectively flush any impending key presses after the fixation dot, but not flush key presses from the blank screen that follows?

sebastiaan · June 2017

Yes, you could have the fixation dot precede the coroutine, rather than being part of the coroutine, if that makes sense. Then you flush the key presses as soon as the coroutines start.

Howdy, Stranger!

Categories

Adding a 'too fast!' contigency to a coroutine for early responses

Comments

Howdy, Stranger!

Quick Links

Categories

Adding a 'too fast!' contigency to a coroutine for early responses

Comments