Hello! I am running an experiment that involves participants answering a prompt by pressing one of two buttons and holding down the button to indicate their confidence. I made a visual confidence bar by using the beta progress bar feature in the builder (and some custom code in a code block). It runs fine by itself, but when I run it after an earlier part of the experiment where I type a word into a textbox, it begins to lag. The first few button presses are registered normally, but then the bar progresses in a jerky fashion and eventually gets stuck. If I put the bar before the textbox routine, there is no issue. I get no error messages or warnings. Every component and routine has different names, so I cannot figure out what is causing this interference. Any tips would be really appreciated!
I have attached a skeleton of the experiment that has just enough to replicate the issue. It can take 30-40 seconds of pressing buttons to make the lagging emerge.
Trying out the experiment using what you have, I was not able to recreate your problem.
I tried holding down the button for a while, works fine, spamming “3” and “4” back and forth worked fine as well. The only “problem” I could create is if the user is holding down a button, then presses the other, then lift the original, the bar would not restart and fill up.
Also, I am not sure what the purpose of this is when used in each frame? I moved it to “beginning of routine” and it functioned the same in terms of how the bar filled up.
if myanswer.rt==[]:
myClock.reset()
press=0
I was thinking maybe for your computer specs, it was unhappy that it was doing so much every frame?
As for a solution (as I cannot recreate your issue), maybe have it so when the user initiates a press, it first sets the part progress to 0, then it begins filling up the bar using a counter instead? Just have the bar fill up at a rate of pixels(or whatever unit) per frame held down, then when the key is lifted, the progress stops.
Thanks for trying this out. That’s odd the problem didn’t come up for you - I’ve been able to replicate it on the other two laptops I tried (both Windows but different models and Psychopy versions), took quite a while on one but sure enough the lagging occurred.
You’re right that line isn’t necessary. In fact, when I removed it entirely nothing seemed to change (thanks for pointing it out).
I tried your suggestion about a counter increasing per frame but it still lead to the issue. I don’t think it’s a laptop spec issue because if I remove the textbox routine or run the bar before the textbox there’s no issue. Very strange.
The only thing I can think of at the moment is the difference in psychopy versions. I’m currently on 2024.2.4, whereas you are on 2024.1.4. Maybe try running it on the same version as myself?
Thanks for coming back to this! I’ve tried it with a few versions including the newest and the error didn’t change.
The lagging also replicated when similar code was used with a slider component rather than a progress bar.
I’m able to split the experiment into chunks so the textbox and progress bar are actually two different projects - isn’t as smooth as if it were all in one but it works.