OS: MacOS Pro M3 PsychoPy version: 2024.2.4, Python 3.8 Standalone Installation: Yes URL of experiment: N/A Run locally: No
What are you trying to achieve?
I want to ensure that mouse clicks and keyboard presses from previous routines do not carry over into the next routine in loops, so that reaction times (RTs) are measured accurately.
What did you try?
I followed the Pavlovia crib sheet suggestion:
Added a fixation “gap” routine of fixed duration (1 second) before my main routines.
In the fixation routine, I added a code component to clear keyboard presses (event.clearEvents()) and record mouse location at the beginning (mouserec = mouse.getPos()).
In Each Frame, I check the mouse location against mouserec as suggested in the crib sheet:
mouseloc = mouse.getPos()
if mouseloc[0]==mouserec[0] and mouseloc[1]==mouserec[1]:
pass
elif ...
What specifically went wrong / my confusion:
I was getting a lot of very short (<1 second) RTs across routines, and this was my way to fix it. Since, I can’t test it on more participants right now if this works or not and I also have doubts if I implemented this correctly, I am asking here.
In one loop, I have two routines back-to-back (picture attached):
Routine ‘order’ – clickable stimuli at the top of the screen; clicking ends the routine.
Routine ‘time’ – slider at the bottom; clicking ends the routine.
In another loop, I have routine ‘recog’ with keyboard presses.
I am worried that in the first loop, if the mouse position never changes during the fixation, then after the fixation ends, the old mouse click might carry over into routine ‘order’ and/or ‘time’.
Specific questions:
In the crib sheet example, after the elif line, what logic should I add for mouse buttons so that old clicks don’t carry over?
Should the fixation duration remain fixed (e.g., 1 second), or should I wait until the participant has released the mouse/keyboard before ending the fixation?
For routines back-to-back in a loop, what is the best way to ensure that clicks/keypresses from one routine don’t immediately trigger the next routine?
Should I just use mouse.clickReset() at the beginning of fixation routine?
What do you mean by “mouse clicks and keyboard presses from previous routines do not carry over”?
The timing/RT for stimuli are captured within that routine, with timing relative to their start time in a routine. After a response is captured (and the routine is set to end with a response) or the routine ends, it goes onto the next routine. The timing doesn’t carry over between loops.
I had two back to back routines in a loop, and in the crib sheet it was recommended to add custom code to clear responses buffer from previous routine, if the same response ends both routines. So, I was worried about how to implement that.
My code using mouseRec and mouseLoc is useful for local experiments using touchscreens, and looks like this:
mouseloc = mouse.getPos:
if t < minRT:
pass
elif mouseloc[0]==mouserec[0] and mouseloc[1]==mouserec[1]:
pass
elif target.contains(mouse):
continueRoutine = False # etc
mouserec = mouseloc
If you are using an actual mouse or a touchscreen online, then you don’t need this code but passing if t < minRT is needed if you don’t have an ITI, to give the participant time to stop pressing the mouse or lift their finger.
If you have an ITI of 1 second and only one mouse click during the routine, you shouldn’t need the code, but if you do use code it should be of the form if mouse.isPressedIn(target) and not if target.contains(mouse)
If you name the response variables two different names, there should not be any problems (e.g. key_resp1, key_resp2).
If you are worried about back-to-back routines having the same time of response (e.g keyboard). Simply add something like a 0.5s delay at the start of the subsequent routine. See below:
You can’t have two keyboard responses with the same name, so I’m not sure what you are explaining here. For keyboard responses there is an option to discard previous key presses, so the .5 second delay shouldn’t be needed (irrespective of whether you have sequential routines with different names or a loop re-presenting the same routine). If you use event.getKeys(), which is no longer recommended, then you need to use code to discard key presses prior to the routine.
You can’t have two keyboard responses with the same name, so I’m not sure what you are explaining here.
Exactly, which is why I am trying to discern what OP’s issue is in terms of the keyboard response.
The 0.5s delay is just a simpler visualization of ISI, as I think one of op’s concerns is if a participant holds down a key response for an extended period of time (~0.25s) they want to be reassured that that key press being carried over won’t act as a response in the subsequent routine (as they have observed sub 1s response times, but depending on task difficulty that might be normal).
Thank you! @stanley1O1@wakecarter
I had added a 1-second ITI but just wanted to make sure that’s enough. I don’t have two response components with the same name, but since the routine is in a loop, the components get called multiple times, which caused some confusion. I think the 1-second ITI should handle everything.
