ENH: Keyboard check function (even if TDT is input device)

[rkmaddox]

Much like we have a quit key that is for the experimenter's use, it would be good to extend that functionality to an arbitrary key or set of keys and return a logical (rather than throw an error) if it had been pressed. This would allow for things like pausing the experiment by the experimenter.

Is the best way to do this to define a general "was key pressed" private function, then have the quit key checking function use that and make a new function that returns a logical?

[larsoner]

I would have the quit-key function and this new function both use the same underlying keyboard-checking mechanism, which would probably mean moving most of the code from the quit-key function to a private one. I can't think of a good naming scheme that makes it clear that we're talking about keyboard strokes, given that we already talk about key presses in our button-press functions (I think)...

[larsoner]

@rkmaddox WDYT about just allowing more than one keyboard controller to be used, and keyboard polling functions check all devices? That greatly simplifies the code (I think), and gives the experimenter flexibility about what to call a different type of event. For example, in the booth the TDT button presses 1-8 could mean one thing, and "p" could be used by the experimenter to pause. Eventually we could also pass back what keyboard device gave the event, but I'd assume YAGNI for now.

[rkmaddox]

I think that makes sense. Does that mean that 1-8 on the keyboard would also be hot? I don't see that as a major problem, I don't think.

[larsoner]

yeah, they would both work

[larsoner]

If that works for your use case, I can probably implement it fairly quickly

[rkmaddox]

It should, thanks.

[drammock]

@Eric89GXL could you include in that PR a little cardboard warning sign
next to MARLO's outside-the-booth keyboard?
On May 19, 2015 12:40 AM, "rkmaddox" [email protected] wrote:

It should, thanks.

—
Reply to this email directly or view it on GitHub
#183 (comment).

[larsoner]

I'll let @rkmaddox add it as part of his protocol :) It will have to be enabled by any given experiment, the default (use button box only) will not change.

[rkmaddox]

The ugly thing is that calls that are simply wait_for_button_press will
now need to specify buttons 1-8 in order to not have any bumped key on the
keyboard count. Since it is not the default to have both controllers
active, I think this is OK though.

Ross Maddox, Ph.D.
Postdoctoral Fellow
Institute for Learning & Brain Sciences
University of Washington
phone: 206-685-4662
http://faculty.washington.edu/rkmaddox/

On Mon, May 18, 2015 at 8:08 PM, Eric Larson [email protected]
wrote:

I'll let @rkmaddox https://github.com/rkmaddox add it as part of his
protocol :) It will have to be enabled by any given experiment, the default
(use button box only) will not change.

—
Reply to this email directly or view it on GitHub
#183 (comment).

[larsoner]

Yeah, I think putting users of the fancy functionality through a bit more pain / explicitness in their code is an acceptable side effect :)