Adding a check for calibration to check_force_quit?

[maddycapp27]

@rkmaddox and I are working on an experiment and would like to be able to re-calibrate the eye tracker at any time. One thought is to add functionality to check_force_quit that will check to see if a "calibration key" is pressed. This doesn't make an abundance of sense semantically, but may be easier/more efficient than writing a new function.

@larsoner @drammock I'd love to hear your thoughts on whether this is a good idea or if you have any suggestions.

[drammock]

so you want to be able to interrupt a block and re-calibrate before the next trial, and then resume where you left off? To do this it makes sense to me to tie into the extant check_force_quit mechanism... if I were being a stickler I'd say that if we do this we should change its name to check_interrupt_keys or check_for_interrupts or something similar.

[maddycapp27]

Right, that's the idea

[rkmaddox]

@drammock That was exactly our inclination, though weren't sure how you guys would feel about renaming. Changing the name of the function could be a hassle, but not insurmountable.

[drammock]

a git grep showed around 10 occurrences or less, so I don't think it will be that onerous. Let's see what @larsoner has to say

[rkmaddox]

Input could be something like dict(quit=['lctrl', 'rctrl'], calibrate=['home'], other_unforeseen_functionality=...)

Might even be able to pass a function handle and a key, which would be really nice for forcing a break, e.g., and telling people to wake up.

[larsoner]

I have suspect check_force_quit will be used in more places than you'd want to use your calibration function. For example, it's probably done in every wait_secs loop, which would mean that it might get triggered mid-trial. Is this what you want, i.e. it to be (effectively) always active, and does something immediately when pressed?

If not -- and you instead want to e.g. check at the end of each trial if some button was pressed during th trial or so -- then we will might want to use something else.

I doubt many people use that function directly. I haven't, just rely on it happening automatically. So renaming probably won't be a problem if we need to go that route.

[maddycapp27]

Is this what you want, i.e. it to be (effectively) always active, and does something immediately when pressed?

Yes, that would be ideal.

Sounds like changing the name of check_force_quit is ok with you all? If so I can start working on that.

[larsoner]

Fine by me. You could even keep check_force_quit around (with same API) as a thin wrapper around whatever new, more generic function you create if you want.

[maddycapp27]

@rkmaddox had the idea of doing it a slightly different way. He proposed that for functions which use check_force_quit we could add a parameter to ask which functions to run. Then we could have default behavior be check_force_quit and allow for a check_interrupts function which would include calibration keys to be run in addition. This way we can continue to check_force_quit throughout without allowing for recalibration mid trial.

[larsoner]

I can't quite see it, can you give the desired API usecase(s)?

[maddycapp27]

So an example would be that wait_one_press currently runs check_force_quit via _correct_presses. We would change this to have options to either keep the existing behavior or add other checking functions by passing an argument into wait_one_press. Default for the new argument (called interrupts for the sake of argument) would be interrupts=check_force_quit but could allow for interrupts=[check_force_quit, check_calibration] or some such. The idea is that we can continue constantly checking for force quit, but only check for calibration during screen_prompt or crm_resp_menu when it is appropriate to do so (i.e. not mid trial).

[drammock]

it seems like the maximally flexible approach would be something similar to our call_on_next_flip functions: interrupt_keys would be a dict of keys that get checked, and each key would have a value that is a function to execute if it gets detected. Of course that requires more substantial code rewriting.

A less flexible approach involving minimal changes is to say that currently we have 2 use cases: force-quit and re-calibrate. Therefore we'll have two params that affect the check_interrupt_keys function (one specifying the list of force-quit keys, and another specifying the list of keys that trigger a re-calibration), and the functions that get executed in each case are hard-written into the check_interrupt_keys function.

What I don't quite understand yet is how what @rkmaddox and @maddycapp27 are envisioning is different from these two extremes.