[open] how to limit allowed response to 'down' key in a sequence of sketchpads?
Hi again!
We have another question for our experiment. In a sequence of 20 sketchpads on which participants have to react as quickly as possible we want to limit the allowed response to the 'down' (arrow key).
In short:
present sketchpad#1 >
participant responds by pressing 'down' key >
present sketchpad#2 >
participant responds by pressing 'down' key >
present sketchpad#3 >
participant responds by pressing 'down' key >
etc.
We have tried this by including 20 keyboard_response items after each sketchpad, however, this solution slowed down the presentation of the sketchpads too much. This is a problem in our design, because we want to measure the responsetimes on all sketchpads for all participants; we want to measure how quickly participants get to the next sketchpad (this is an outcome variable).
We have also tried to implement an inline_code before the sketchpad sequence:
from openexp.keyboard import keyboard
my_keyboard = keyboard(exp)
my_keyboard.set_keylist( ['down'] )
and:
from openexp.keyboard import keyboard
my_keyboard = keyboard(exp, keylist=['down'])
but these options didn't seem to work
We wonder whether it is possible to limit the allowed response inside of the script of each sketchpad or by adding another inline_script at the start of the sketchpad sequence?
We hope someone can provide us with the solution
Many thanks in advance!
Comments
Hi Martine,
I'm not completely sure whether I understand your question correctly. But herewith already a few comments.
This doesn't mean that after every sketchpad, participants have to press the down key 20 times, does it? By looking at your trial sequence I assume that they press once after every stimulus.
OpenSesame's prepare-run strategy makes sure sequences are prepared in advance: All sketchpads are constructed at the start of a sequence, such that they can be used with minimal delay during the execution of the sequence.
In other words, the delay caused by the preparation time will normally occur prior to the start of your sequence, and not from sketchpad to sketchpad during your sequence.
Therefore, I think a trial sequence like you described should work fine:
Additionally, you could try to use the Legacy back-end for your experiment, because this one is fastest in preparing the sketchpad items.
If in your experience this still slows down the presentation of the sketchpads too much, could you perhaps indicate in a little more detail what you mean exactly by that?
I think the problem is that you're not getting any keyboard input yet. Adding the
get_key()
function to your inline code should solve this:Note, however, that this way of pulling a keyboard response is not really faster than using a keyboard_response item in the GUI.
Do those comments help a little bit? Feel free to post again, perhaps with a little bit more detail about your experiment (e.g. a screenshot of your overview area, or the code of your experiment).
Best,
Lotje
Did you like my answer? Feel free to
Thanks for the quick response!
I will explain what we want to achieve in our experiment. Participants are presented with a picture of a hallway. At the end of this hallway, there is an object. Everytime the 'down' arrow key is pressed by the participant, this object increases in size (so that it appear that the object is coming towards the participant). After 20 presses, the object is now very close to the participant and the next trial starts. The rationale behind this is that the faster participants bring the object towards them, the more they 'want' the object.
In our experiment, we present 20 sketchpad items in a sequence. Everytime the participant presses the 'down' key, the next sketchpad in the sequence should be presented on the screen. However, we want to limit the response that participants can give the the 'down' key only. When they press any other key, nothing should happen.
We tried what you suggested with adding a keyboard_response (allowed response set to 'down') after every sketchpad item. However, there appears to be a noticable amount of lag between each sketchpad. It is very important that the transition between the sketchpads should be very fluent because the response time between presses is our outcome measure.
Below is a screenshot of the sketchpad sequence:
Thanks again for helping!
Martine