To preface, OS is windows 8.1 / 10, running psychopy 1.83.04 and have built my study using coder.
I’m having trouble with what appears to be a slight flicker / frame rate issue.
To give some context, within a 1000 ms time period, I have a set of stimuli that should remain static for approximately 600 ms, and should then change orientation and remain static but at this different orientation for the remainder of time. I have achieved this by simply setting the stimuli to one orientation for approx. 42 frames (60 hz, 16.6 ms per frame; 672ms) and then alter the orientation for the remainder frames.
The problem is that from merely observing the stimuli it seems that there is a very subtle flicker, which indicates to me that it is likely that stimuli are orienting to all directions at random for a single frame or so (as this is the behaviour of the global form stimulus when it is simply set to draw with no frame conditionals). Regardless, the point isn’t so much as to what its doing specifically, but that they are making an additional movement within what appears to be a single frame, which creates a flicker. This is of course something I don’t want in my EEG experiment!
I can’t exactly tell where it is occurring (and I am not at all deft at trouble shooting it!)
Below is a sample of the script.
if t < 60.0: #trial is 1 min long
frameN += 1
if frameN >= 59: #refresh rate of 60hz; setting to 59 makes stimuli timing consistent and not losing 1-2 stimuli per trial
frameN = 0
print "frameN reset"
if frameN in range(0,43,42): #hav altered these between 42/43 to attempt a fix if i was somehow missign a frame here, but no fix
globForm.oris = numpy.random.rand(N) * 360 #what is the 360 for? the 360 makes the values integers divisible by 360 degrees rather than floats in the range of 0-1
if frameN in range(42,61,18): #have altered these between 18/19 frames to attempt a fix if i was somehow missing a frame here, again no fix
globForm.oris = numpy.random.rand(N) * 360
It could be a simple miscalculation on my part with regard to the framerate; but if it is then I’ve missed it. I don’t know whether this is an obvious issue that I’m missing or something deeper. But if anyone has any insight it would be massively appreciated. I’m in the midst of pilot testing currently so if I’m able to get this fixed prior to data collection that would be absolutely fantastic.
P.s. I am unsure if this is relevant, but on the off chance it is, i will clarify by saying that frameN is set to reset after 59, rather than 60, as there was a loss of 1-2 stimuli per trial (depending on if framerate is running optimally), which was fixed by moving this to 59. There was a loss of - on average - 16 ms between stimuli presentations. Reducing to 59 means it resets 1 frame earlier which covers the frame loss by giving the overall 1 min an additional 16 frameN’s. Furthermore when looking at the timing of the presentations in the output, it makes them much more consistently timed around the 707-714ms time period, which is much less variation than when frameN was set to 60.
Thanks so much in advance for any help!