Keyboards

Figure 4: A keyboard customized for gaming.

Basically every computer has a keyboard, which provides a large array of buttons designed around the human hand and can detect multiple simultaneous key presses. The keyboard can be a compelling musical controller along the lines of the piano, but using it can trap the musician in the keyboard/mouse/monitor interaction model. The keyboard does not need to be used in the standard way, it could be a standalone instrument strapped onto the body like a guitar. It is a cheap and useful controller, if care is taken to escape the standard keyboard interaction.

Pd provides a number of objects for accessing the keyboard data. [key], [keyup] and [keyname] report key presses as long as a Pd window has focus. They are standard Pd objects and work on all platforms. [key] outputs the system-specific key number on key down; [keyup] outputs the system-specific key number on key up; [keyname] outputs the key name on the right outlet, and the state of that key whenever a key is pressed or released. [gemkeyboard] and [gemkeyname] report key presses when the Gem window has focus. [gemkeyboard] outputs the system-specific key number on key down while [gemkeyname] outputs the key name on the right outlet, and the state of that key whenever a key is pressed or released. It is also possible to get all of the keyboard data using [linuxevent]. With this object, Pd will always get the key press data regardless of whether Pd or Gem has focus since it reads directly from the keyboard device.

As with the mouse, the OS and the Pd application also use the data from the keyboard, leading to the same problems. The same workarounds that work for the mouse apply when usingthe keyboard and a controller. Also, when Pd is running in -nogui mode, it will never have focus since there would be no GUI component running, therefore all the current keyboard objects but [linuxevent] would not report any data in -nogui mode.