adammorrissirrommada
commented
5 years ago My feeling is that we could get rid of alwaysOn altogether and not lose any performance (using instead, s.on==0 and s.duration == Inf), with a minor change to the code.
Currently, these are the NS params that are evaluated in that section:
- s.alwaysOn
if its false, additionally
- s.on
- s.duration
- s.cic.screen.frameRate (x 2)
The few additional calculations in the else clause are modest and draw only on local variables. (fast)
If we cached s.cic.screen.frameRate (slooow) into a non-NS member variable of s in beforeExperiment() (fast) , there'd be only two ns params evaluated in the latter section. That's the same number that you'll end up with if you add a further check of s.on to the alwaysOn clause.
This would break existing experiments that use alwaysOn, but the fix needed is trivial. If we wanted to smooth the transition, we could make a local, non-ns variable called alwaysOn, and add a set() function that detects it is being used and to issue an error with instructions for fixing it.
(by the way, we should do the caching frame rate bit regardless!)
cnuahs
bartkrekelberg
It is currently possible to specify .alwaysOn ==true, and also .on = something.
The .on will be ignored (overruled by alwaysOn) in the base class.
But the user can have beforeFrame code that uses the .on values. : if trialTime >s.on; drawSomething .
This is confusing at analysis time when .startTime will equal firstFrame and yet the stimulus may only draw later
I think the best way to address this is to check that .on is empty or NaN whenever alwaysOn is true. Setting both is contradictory and never (?) a good idea. So at the very least a warning is in order, and probably an error?