presenting canvas till keypress

bluelook

hello,

I'm trying to present dynamic instructions to the user (taken from xlsx file, they differ by gender), hence i am creating a dictionary in python and then trying to present it via canvas, again with python (created in prepare phase). Each instruction should remain on the screen till any key (let's say 'space') is pressed, and then move on the next one.

For canvas to stay, i figured out i need some "delay", so i used clock.sleep(1000) in run phase. That was a complete guess and it worked, but i don't know why. After that i used keyboard (created in prepare phase) to proceed to the other canvas.show(), but now there was no need in clock. I'm a bit confused.

I've been searching the documentation and the forum for a while, but i don't find anything concrete (especially for v3.2). attaching the part of the code for two instructions screens commands.

any help is appreciated,

thank you

Lena

bluelook

bluelook

anyone? pretty please ?

eduard

Hi Lena,

What exactly is your problem? To present instructions in a piecemeal fashion, you just need multiple sketchpads (or multiple text widgets in a single sketchpad), and set the duration to keypress. No need for any timing information.

Does that help?

Eduard

bluelook

Hi Eduard,

Thank you for your reply.

Since my experiment has dynamic instructions varied by gender, i am reading them from xlsx file in a python script. Therefore multiple sketchpads solution didn't work for me, and i have created one script which is reading the corresponding instruction till a"space" key is pressed in a piecemeal fashion. It's working not that bad, however, i added a delay for the canvas (which was a complete guess) clock.sleep(1000) in the beginning of the script. This requires two keypresses once the first instruction appears and seems like it's not supposed to be like that, and i did it wrong.

here is how i did it:

regarding your second suggestion, I am not sure how to use multiple text widgets in a single sketchpad till keypress each, i have searched the documentation, however failed to find it. If this also may solve my problem, i would be happy to use it.

thanks again for your help!

Lena

eduard

Hi Lena,

I don't see a reason why two keypresses should be required from your script. Could you share the entire experiment with us? Don't forget to include the xlsx file.

Thanks,

Eduard

bluelook

hello Eduard,

Due to my lab privacy reasons, i had to omit experiment parts, so only the script part remained in the experiment.

https://drive.google.com/file/d/1JUVlp_eAvAEzdKuvpC4IcSQyAMpk0a5D/view?usp=sharing

it's all in hebrew, however, you may notice that the 'experiment_steps' part (the last in each instructions block) requires two key presses to move on to the next.

it's either 5th or 6ths screen, depends on first/second block.

hope it's not too confusing. i'm attaching the xlsx as well, however it's in the pool as well.

thank you!

Lena

instructions.xlsx

eduard

Hi Lena,

The problem is in these lines:

if var.subject_parity == 'even':
   s.text(var.screen_dict['welcome'][var.sex])
   s.show()
resp, time = s_keyboard.get_key()
s.clear()

That you have in each block as first code executed. Specifically, Whether you show the welcome text or not depends on the subject parity, but they keyboard item is being called every time. So basically, even if there is no new stimuluspresentation, there would always be a keyboard required, which effectively looks like a double keypress on the previous item. Does that make sense?

I don't know how exactly you want the sequence to be, so I won't fix it for you. But this information should be sufficient, right? Let me know if not.

bluelook

hi Eduard,

This actually makes lots of sense!

So to solve this, basically, i need just to ident

resp, time = s_keyboard.get_key()
s.clear()

into the "if" and it will work fine. Am i correct?

Thank you so much, no idea why i left it out in the first place :)

For the overall knowledge of mine, what does clock.sleep(1000) do in this case? why do we need it for canvas presentation?

thanks again

Lena

eduard

Hi Lena,

I think so.

clock.sleep just halts the experiment for as many milliseconds as you specified in the brackets. If you wouldnt include it (and there is no other delay in your experiment),your experiment would instantly continue and present the next trial, so that essentially, you just see flashing on the screen.

Specifying the sleep, is basically setting the duration of how long you want your stimulus to be seen.

Does that clear things up?

Eduard

bluelook

hi Eduard,

hmm, a little, yes.

so is the keyboard line

resp, time = s_keyboard.get_key()

the reason the canvas stays longer and actually waits for user's input? cause it stays much longer than 1000 ms i specified.. :)

thanks

Lena

eduard

That is what I meant with "there is no other delay". If you have a keyboard response following your stimulus you don't need to sleep. In fact, you can specify the duration inside they response item (the timeout field).

Suppose you have a sequence like this:

1) Fixation

2) Stimulus

3) Response (infite timeout)

If you dont specify a sleep after the fixation, the experiment will immediately continue to the stimulus, and from there directly to the response. What you will see on the screen is only the stimulus, because the fixation is replaced right after it was presented by the stimulus. The response does not change the visuals (as no display changes are associated with it)

In contrast:

1) Fixation

clock.sleep(1000)

2) Stimulus

3) Response

Now the Fixation stays on the screen for 1000 ms, the rest doesnt change

and also:

1) Fixation

clock.sleep(1000)

2) Stimulus

clock.sleep(1000)

3) Response

Now the Fixation stays on the screen for 1000 ms, and the stimulus display is presented for 1000 ms before the response item is being called and subjects can respond. Importantly, visually this extra sleep after the stimulus won't make a difference, but for your response time the effect is huge (basically 1s added to all response times bigger than 1000 ms, and no response for all responses smaller than 1000 ms). So this scenario is what you don't want.

Makes sense?

Eduard

bluelook

i think it's more clear now, thank you Eduard