Multiple keyboards, one computer.

541 views
Skip to first unread message

Justin Fine

unread,
Aug 29, 2013, 8:06:55 PM8/29/13
to psychop...@googlegroups.com
I am trying to design an experiment with two monitors, but using only a single tower.  The study requires two people to have response capabilities simultaneously.  We don't have any button boxes, so I was just going to use keyboards.  My question: is is possible to have two separate ps/2 or USB keyboards running at the same and receiving keypress events from the same system within psychopy?

I really appreciate any direction or help from someone who has an idea.

Justin Fine  

Jonathan Peirce

unread,
Aug 30, 2013, 6:21:02 AM8/30/13
to psychop...@googlegroups.com
I can't think of a reason that wouldn't "just work" but give it a try!
Jon
> --
> You received this message because you are subscribed to the Google
> Groups "psychopy-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to psychopy-user...@googlegroups.com.
> To post to this group, send email to psychop...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/psychopy-users/61a2f68c-585f-41be-a935-eb9945e11aa8%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Jonathan Peirce
Nottingham Visual Neuroscience

http://www.peirce.org.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.




Justin Fine

unread,
Sep 7, 2013, 9:26:31 PM9/7/13
to psychop...@googlegroups.com
I should have been clearer.  But first, thank you for the reply.  I need to be able to discriminate which keyboard the response came from.  For example monitor (1) & keyboard(1) pairing, and monitor (2) and keyboard (2) pairing.  Is this possible, beyond going thru parallel port/USB switch boxes?

Yigit Turgut

unread,
Sep 8, 2013, 12:30:22 AM9/8/13
to psychop...@googlegroups.com
I don't feel like elaborating so just cutting to the case ; NO it will NEVER work. (:

A Computer is designed to operate with a single keyboard.


On Sun, Sep 8, 2013 at 3:26 AM, Justin Fine <jmf...@asu.edu> wrote:
I should have been clearer.  But first, thank you for the reply.  I need to be able to discriminate which keyboard the response came from.  For example monitor (1) & keyboard(1) pairing, and monitor (2) and keyboard (2) pairing.  Is this possible, beyond going thru parallel port/USB switch boxes?

--
You received this message because you are subscribed to the Google Groups "psychopy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-user...@googlegroups.com.
To post to this group, send email to psychop...@googlegroups.com.

Sol Simpson

unread,
Sep 8, 2013, 5:06:16 PM9/8/13
to psychop...@googlegroups.com
The only way I know of to do this if using multiple kb devices connected directly to the computer is to write a special purpose keyboard ( and mouse if desired ) driver that includes the keyboard device id available at that lower level in custom keyboard events generated by the driver. These custom events would only be accessible by the experiment runtime. Standard kb events can still be passed to the OS in parrallel if desired. Implementing this is a lot of work, but is possible to do, at least on Windows and OS X. Being possible, and it ever happening, are likely two very different things in this case I would think. :)

Other option, which is still on the higher end of implementation time, would be to connect the second kb to a microcontroller that can act as a USB keyboard /host/ and then forward the kb events for this kb from the microcontroller to the computer using a serial - USB interface. The events could then be accessed using py serial.

Thanks.

Sol

Michael MacAskill

unread,
Sep 8, 2013, 5:52:20 PM9/8/13
to psychop...@googlegroups.com
What sort of responses are you after?

If are just after binary responses, or some other sort of restricted set that doesn't require the full range of keys, can you just physically mask-off differing sets of keys on each keyboard? Or permanently engage the caps lock on one?

Cheers,

Mike

Yigit Turgut

unread,
Sep 9, 2013, 3:39:08 AM9/9/13
to psychop...@googlegroups.com
OP mentioned 'simultaneously' which he can NEVER achieve. Problem boils down to which keyboard is assigned higher privilege by the System Administrator.

As Michael stated if you want binary response just use the mouse ; A Computer is designed to operate with A Single keyboard only.

Unless you can design your own architecture and run that computer in a universe where there is no time allowed thus all instructions can execute simultaneously.

Sol Simpson

unread,
Sep 9, 2013, 10:48:35 AM9/9/13
to psychop...@googlegroups.com


On Monday, September 9, 2013 3:39:08 AM UTC-4, Yigit Turgut wrote:
OP mentioned 'simultaneously' which he can NEVER achieve. 

As long as the keyboard event access that contains the keyboard 'identifier' only needs to be accessed from within the experiment runtime , both options I suggested would support simultaneous access to multiple kb inputs and are technically possible; it has been done before for software outside of psychopy (using Windows and OS X, Linux possibilities for this are not known to me). Both options could also be done in a way so that one keyboards events are received only by psychopy and the other keyboards events are received only by the standard OS event notification system. 

As previously mentioned though, what is technically possible and what is realistically going to be implemented in an experiment software package developed, as time permits, by very thoughtful and generous volunteers are two very different things. Especially since this would not be an enhancement implemented in 1-2 hours. ;)    

On Sunday, September 8, 2013 5:52:20 PM UTC-4, Michael MacAskill wrote:
Or permanently engage the caps lock on one? 
 
Michaels suggestion may work if the restriction ideas he suggested are OK for the OP's purposes and if using the iohub to get keyboard events. On all the OSs supported by PsychoPy, I believe the default behaviour of the OS is to /combine/ the input from multiple attached keyboards and /present/ it to the application running as a since keyboard event stream. Normally keyboard events are only available to the window that is currently active / has focus.  iohub receives keyboard events system wide, not just those that the OS sends to the currently 'active' window. If it is OK to have a kb modifier permanently enabled on one kb and not on the other, then you could filter keyboard events you get from the iohub by checking which events either have, or do not have, a given keyboard modifier present in the event. The caplocks or numlock modifier may be good candidates. You would then just use 'mod pressed' keyboard events for one window and 'mod absent' events for the other window.

While not ideal, it could work keeping in mind: 1) You somehow need to ensure that the kb modifier being used is psychically enabled on one kb and disabled on the other. 2) Both windows would need to be experiment based windows that you control so that you can use the iohub keyboard events as needed filtered for each window.

Now that I think about it, if both screens each have 1 single full screen psychopy window. The 'filtering by modifier' approach may work using psychopy's currently built in keyboard event system and iohub may not be needed here, since one of the two psychopy windows will always have focus I assume, so keyboard events targeted at either psychopy window will be available during a psychopy exp. Using the built in psychopy keyboard event system would have to be tested first, I am not 100% sure.

Yigit Turgut

unread,
Sep 9, 2013, 10:57:30 AM9/9/13
to psychop...@googlegroups.com
How are you planning to execute two instructions simultaneously ? It's a sequential drive thus you can NEVER achieve it, one has to wait for the other to finish the input and the one which will be waiting is the one which is assigned as low priority by the system administrator/kernel driver/device driver or whatever you want to call it. From a macroscopic point of view you might observe it as simultaneous (it will take some microseconds between input1 and input2 depending on the clock rate of your cpu) but it will never be simultaneous, it's just theoretically impossible.

I suggest you to take a look at the following link for a 'deeper' understanding of why it can't be done ;

1-http://en.wikipedia.org/wiki/Von_Neumann_architecture
2-http://en.wikipedia.org/wiki/Simultaneity

Cheers
y.




--
You received this message because you are subscribed to the Google Groups "psychopy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-user...@googlegroups.com.
To post to this group, send email to psychop...@googlegroups.com.

Jared Roberts

unread,
Sep 9, 2013, 11:19:01 AM9/9/13
to psychop...@googlegroups.com
I don't think that he was meaning simultaneous as in "at the exact same nanosecond".  Yeah, one event is always going to happen after the other, but we're talking about on the order of CPU clock cycles.  I'm pretty sure that the idea here is that two people can be using two separate keyboards to make responses and that psychopy can collect them and differentiate between them with some modicum of temporal resolution.


In my opinion, Mike's approach is the easiest and most pragmatic, although a quick test of concept revealed that having the caps lock key on didn't actually change the key name. So as long as the number of responses is less than the number of available keyboard keys divided by two, you could achieve this feat simply by having the participants use two separate sets of keys to make responses on their respective keyboards.

--
Jared Roberts
Graduate Student
The Yassa Learning and Memory Laboratory
Johns Hopkins University
"A lost cause can be as spiritually satisfying as a victory." - Robert Heinlein

Jared Roberts

unread,
Sep 9, 2013, 11:31:35 AM9/9/13
to psychop...@googlegroups.com
Just to give an idea of the temporal resolution we're talking about, here are 2 events from my log file along with RT's in milliseconds:  a|2052.145; x|2058.937.  This resulted from using my Macbook's internal keyboard along with a USB connected keyboard.  I was pressing 'a' on the USB keyboard with my left hand and 'x' on the internal keyboard with my right hand. There are like 6 milliseconds difference between the two, but that's probably my own motor function.

-Jared

Sol Simpson

unread,
Sep 9, 2013, 11:32:45 AM9/9/13
to psychop...@googlegroups.com
I think the OP meant that they wanted to get events from 2 keyboards during an experiment and differentiate which events came from which keyboard within the experiment logic; this is what I was addressing. 

Forgetting about multicore or multi-CPU computer considerations, then /nothing/ CPU bound is ever done in a literal 'simultaneous' or 'parallel' fashion, that is a basic fact of single core / cpu systems. If I understood the OP correctly, this is not what was being asked to achieve though.  

Although I think this is off topic for the OP's question, if you do expand the general topic you are raising to the world of current multi core CPU's and OS's that actually can use them (i.e. /not/ DOS, but /yes/ for any recent version of the OS's supported by PsychoPy), then it is often possible for N instructions to be executed in parallel, where N == the number of cores. The OS and software being run need to be multicore 'aware' of course to take full advantage of parallel processing. This is what the psychopy process and iohub process are doing when running on a multicore system if each process is assigned to a different set of available cores (either automatically by the OS, or explicitly using the iohub.Computer class process affinity related methods).  

Thanks again.

Yigit Turgut

unread,
Sep 9, 2013, 12:09:41 PM9/9/13
to psychop...@googlegroups.com
Actually it can never be truly simultaneous even if its a multicore cpu as well. Very roughly speaking, to execute two different functions/instructions at different cores, you construct 'jobs' and send to cpu, they execute with very close delays (1 cycle min, depending on the vector you send the job) but to read back the response you are stuck with sequential reading again. I worked on this problem at wide range of different systems, they can NEVER be in the same 'time frame'. Surely, my approach and results are based on my understanding of the definition of precision, as somebody wrote ; it will be considered as simultaneous for most of the users with a sub-second difference. Clock of average human brain is much smaller (bigger cycles) than a 20 years old computer already so for the OP's purposes it can do the trick but call it something else ; not simultaneous (:


Sol Simpson

unread,
Sep 9, 2013, 8:12:51 PM9/9/13
to psychop...@googlegroups.com
Agreed that this would be the best solution if it can be used from a logistical POV by the OP.

regarding cap lock, when using the default pyglet based keyboard events,I do not think the key constant will be changed if caps is on or off, but do the key modifiers for the event indicate if cap lock is on or not? If the answer is no, then using psychopy.iohub would solve this, as cap lock is one of the reported keyboard event modifier types and I believe the case of the keyboard event 'key' attribute will be upper or lower case depending on the cap lock state ( I.e. 'a' vs 'A' will be in the kb_event.key field when caps is off vs. on) as well.

Thanks, Sol

Reply all
Reply to author
Forward
0 new messages