(using PsychoPy standalone) Space by itself doesn't end 'show subject relative position' phase

[datalowe]

All demos include this piece of code:

# show the relative position of the subject to the eyetracker
# Press space to exit
controller.show_status()

It says 'press space to exit'. However, on my setup (Windows 10, PsychoPy standalone v2020.2.10, running the experiment from PsychoPy Coder view), this by itself doesn't work. I first need to do a mouse click and only then can I hit space to proceed.

After the experiment has finished, I can see in the coder view that any keyboard input I entered before doing a mouse click have resulted in corresponding characters being written in the script. It appears then that for some reason, 'focus' isn't shifted to the experiment window (even though it's in the foreground and fullscreen). Instead, Windows keeps routing any keyboard input to the coder window.

[yh-luo]

I encountered this problem in our lab Window machine too. Unfortunately, it acts the same way for all the PsychoPy experiments on Windows 10. I suspect it was caused by Windows 10 updates, since this problem exists only on our Windows machine after some updates. Mac and Linux (Fedora) machines are free from this problem.

An easy workaround is to use Alt + Tab to select the PsychoPy window. In this way, PsychoPy is focused and the keyboard inputs are correctly detected by PsychoPy. I need to do this every time the experiment is launched on the Windows machine. Because this problem is not rooted in this project, I can't really do much to that.

[datalowe]

I see, and you're right of course that it's not something that can/should be fixed by this project then. On the same Win 10 computer I use I haven't noticed the problem when running other PsychoPy experiments, but these I initialize through a .bat script (ie through the Windows command prompt, referencing the Python executable without opening Builder/Coder). If it's OK I'll leave this issue open for a bit longer so that I remember to try a few things out and see if I can find a good workaround and/or open an issue about this on PsychoPy's own repo.

[datalowe]

Hi, I finally had some time to look into this a bit more. I haven't found exactly what happens yet, but partly for my own sake I'll write down what I found so far:

If I run experiments on the Windows computer I have at home, without involving eyetracking or movies, there are no issues with the keyboard. Windows' "focus" switches over to the PsychoPy experiment, and keyboard input only affects the experiment. So for instance, this works:

from psychopy import visual, core
from psychopy.hardware import keyboard

win = visual.Window(
    size=(1024, 768), fullscr=True, screen=0, 
    winType='pyglet', allowGUI=False, allowStencil=False,
    monitor='testMonitor', color=[0,0,0], colorSpace='rgb',
    blendMode='avg', useFBO=True, 
    units='height')

key_resp = keyboard.Keyboard()
text = visual.TextStim(win=win, name='text',
    text='Waiting for space signal',
    font='Open Sans',
    pos=(0, 0), height=0.1, wrapWidth=None, ori=0.0, 
    color='white', colorSpace='rgb', opacity=None, 
    languageStyle='LTR',
    depth=-1.0);

continueRoutine = True
while continueRoutine:
    keys = key_resp.getKeys(keyList=['space'], waitRelease=False)
    continueRoutine = not bool(keys)
    text.draw()
    win.flip()

win.close()
core.quit()

If however a movie is added, keyboard input is not correctly 'caught' entirely by PsychoPy. So, if I change the above experiment to also include...

movie = visual.MovieStim3(
    win, 
    "infant/seal-clip.mp4", 
    pos=(0, 0),
    size=win.size
)

... then, if I run the experiment and hit the space, the task still ends as expected. However, I can see in the coder view that a blank space (' ') has been typed into the code editor, meaning the input was sent to both the task runner and the code editor. Note that the above snippet is enough - it doesn't matter if one attempts to show the movie or not, just generating the MovieStim3 instance is enough to produce the bug.

I looked at what happens inside of the MovieStim3 code. It turned out that nothing about the initialization of MovieStim3 itself was causing the bug (I tried commenting out the whole __init__ method in the PsychoPy source code, but the bug kept happening).

What turned out to be vital for the bug was this single line in the source code for MovieStim3: from moviepy.video.io.VideoFileClip import VideoFileClip. Something goes wrong here because the import isn't done in the main script, ie we first import/use visual.MovieStim3 and this in turn triggers an import of VideoFileClip.

Looking again at the 'experiment skeleton' I pasted above, the bug can be stopped by adding an explicit import inside of the task itself, like this:

from psychopy import visual, core
from psychopy.hardware import keyboard

from moviepy.video.io.VideoFileClip import VideoFileClip

win = visual.Window(
# ... [continuing as above, including the movie instance generation]

I still need to go to my workplace, for access to an eyetracker, to test if adding this explicit/'main script' import would also solve the issue described in this thread.

Misc notes:
I found this thread on the PsychoPy forums which seems to describe a related issue in 2019, so the issue seems to have been around for some time.

Instead of doing an explicit import of VideoFileClip, one can add from moviepy.video.VideoClip import VideoClip, which is more specific (it is itself imported by the .py file for VideoFileClip).

[datalowe]

Continuation of last bit of 'Misc notes':
Going even further down the rabbit hole, adding 'from moviepy.config import get_setting' (which is used in moviepy.video.VideoClip) is also enough on it's own for solving the issues. I'm not able to figure out why this works however.

Substitutingmoviepy.video.VideoClip with imports used in the 'config.py' file itself (in moviepy's source code) doesn't seem to do anything. So there's presumably something happening in 'config.py' that is causing the issue.

There's a number of conditionals in 'config.py' checking to see if Windows is being used (if os.name == 'nt':), so it makes sense that something in there would cause issues on Windows specifically.

That's about as deep in the weeds I'll go. If simply inserting the import turns out to work okay, I'll be satisfied with that.

[datalowe]

I can now confirm that adding from moviepy.config import get_setting at the top of the script does work for avoiding this issue. I haven't tried this on Mac/Linux, but it seems very unlikely that the import would break anything there.

So, this project could add the import to the top of the demo scripts and/or mention it in the README. Or, since it's not really this package's (possibly not even PsychoPy's) responsibility to make this work, this issue could be closed and other users can hopefully find it in the archive. I'm fine with whichever, so @yh-luo please go ahead and close this issue once you've decided what to do :)

[yh-luo]

@datalowe Thank you for the detailed report!

Though the solution you provided is easy, it's not that intuitive to introduce moviepy in the demos. I'm worried that it would further confuse the users because some of them (using Mac/Linux) might not encounter this problem.
For now, I will update README to refer to this issue. If that's not enough we can work a new way to tackle this.

Thank you again!