HID for Pd

I am interested in physical interfaces to computer music. Here are some objects I have written for Pd to enable the use of HIDs like joysticks, mice, tablets, etc. For more on this topic, check out my NIME research page.

unified [hid]

Here is an alpha test release of the cross-platform, unified [hid] object. It uses a event type/code naming scheme taken from the Linux input event system, since it is much cleaner than Microsoft DirectX, Apple HID Manager, or the USB HID schemes.

download hid-0.6.tar.bz2 for GNU/Linux and MacOS X

Additions:

Keyboards are supported under GNU/Linux thanks to Georg Holzmann. Thanks to August Black for tracking down the segfault bug in GNU/Linux. Standard joysticks and mice are supported almost exactly the same in GNU/Linux and MacOS X. Tablets are supported in GNU/Linux, but Wacom wrote a whack driver for MacOS X, so tablets are not yet supported in MacOS X. I don't have a gamepad, so I haven't tested it yet.

GNU/Linux HID Utilities

For using HIDs on GNU/Linux, I cobbled together a handy little utility, lsevent, in the same family as lsusb and lspci. Its just a simple C file, you can compile it like this: cc -o lsevent lsevent.c

lsevent.c

Also, there is ff-utils, which are part of the force feedback support for GNU/Linux. Included is the very handy evtest for viewing raw data directly from a evdev device. You can get them here:

ff-utils.tar.bz2

Force-Feedback

Gerard van Dongen-Gilcher's Force-Feedback Externals

I have started working with force-feedback AKA haptic feedback thanks to Gerard van Dongen-Gilcher's force-feedback objects.

ifeel-0.1.2.tar.gz

I wrote a external for linux for the iFeel mice. It works in conjuction with this linux iFeel driver. In its current form, the ifeel.o kernel module crashes if you input data too quickly, I am looking into this. I suspect it is a bug in the linux kernel module.

rawHID(e)

Some of the objects are now deprecated! Use [hid]!

My first version of some HID objects are based on the Linux input events system. They give you the data from the input event system, rather than from the GUI. This means that your mouse/tablet movements are not constrained to the size and resolution of your screen.

There are two similar objects that I know of: [MouseState] from cyclone, and J. Sarlo's [joystick] . These objects differ in key ways:

[MouseState] is a version of the Max/MSP object for compatibility. So it is limited to only one mouse button, just like the Max/MSP object. It also outputs the position data in terms of absolute screen pixels. The [linuxmouse] outputs directly from the event system, so the position data is relative, and not tied to screen location or focus. Also, [linuxmouse] allows you to use the mouse wheel and up to 7 mouse buttons.

[joystick]'s outlets are dynamically created, so that different joysticks will cause different amounts of outlets. [linuxjoystick] has a fixed amount of outlets, so that your patch doesn't need to change with each joystick. The disadvantage of this is that this object doesn't support axes beyond X, Y, twist, throttle, and 1 hat switch. You can make a custom object for your joystick using an abstraction based on [linuxevent]. See the help for an example.

[linuxevent] gives you the raw input event data on four outlets: time, type, code, and value. The time outlet doesn't work yet, but it isn't essential. Christian Klippel has written a similar object for jMax.

Currently they are only for Linux, but I am working on the libSDL port now, which should work on Windows, GNU/Linux, and MacOS X. I have completed [linuxmouse], [linuxjoystick], and [linuxevent]. A [rawtablet] object would be trivial, but I don't have a tablet, so I can't test it. But you can make a tablet abstraction using [linuxevent].

Download linuxhid-2003.11.17.tar.gz

$Id: hid.html,v 1.18 2006/11/26 23:26:27 hans Exp $