The PsychoPy in-house generated code has a section that usually looks something like this:
if t >= 0.0 and opening_text.status == NOT_STARTED: # keep track of start time/frame for later opening_text.tStart = t opening_text.frameNStart = frameN # exact frame index opening_text.setAutoDraw(True) frameRemains = 0.0 + 1.0- win.monitorFramePeriod * 0.75 # most of one frame period left if opening_text.status == STARTED and t >= frameRemains: opening_text.setAutoDraw(False)
In some dodgy Frankenstein-ing of this, I’ve ended up using the following bit of code:
frameRemains = 1000 + 1.0- win.monitorFramePeriod * 0.75 if audio_feedback.status == STARTED and t >= frameRemains: audio_feedback.stop() if audio_feedback.status == FINISHED and correct_text.status == FINISHED or incorrect_text.status == FINISHED: continueRoutine = False
This was a budget solution to a problem: PsychoPy was always cutting audio_feedback short when it played. If the participant took a short time to respond then the whole of audio_feedback would play. However if they took a long time then it would often cut short, and sometimes not even play at all.
I found that replacing 0.0 with 1000, resulting in a much larger frameRemains variable, fixed this issue on a surface level - audio_feedback is no longer cut short. However I don’t know the possible further implications of this, and it’s obviously not great to Frankenstein code when you don’t know what it’s supposed to be doing…
What are the implications of what I’ve done here? Is there a better way to fix the initial problem?