You misunderstood the kind of object I am building. Look at J. Sarlo's joystick object. What I am doing is like that except with fixed outlets for the axes rather than dynamically assigned axes. A generic version of that would not work very well.
As for the event interface object you specify, I personally would find it
less useful than specific (albeit very similar) objects for specific devices.
When I choose a controller, I don't think of what kind of event interface I am
using, but rather whether I am using a mouse, a joystick, etc.
Its a matter of different approach. Defining the interface and then implementing it, versus building the interface to mirror the implementation. I prefer to design the interface first, then implement.
Plus since I work on Windows, MacOS X and Linux, I want my objects to be cross-platform. And I am not sure how compatible the three different HID schemes are (I have only used the linux event system, and read about the MacOS X HID stuff).
.hc
On Wed, 9 Apr 2003, Christian Klippel wrote:
hi,
Am Mittwoch, 9. April 2003 07:18 schrieb Hans-Christoph Steiner:
The problem with writing a generic event interface object is that the number of outlets would change for every device, so for example, if you wrote your patch for a mouse with a wheel, that would give you three outlets for the x, y, and wheel axes. But then throw in a mouse with no wheel, and you'll get one less outlet, and your patch is broken.
huh ? sorry, but you are completely wrong with that.
exactly that is the reason the event interface exists. you have uniform messages for every kind of (not only) hid input device, like mice, joysticks, keyboards, etc .....
and that is the reason i made "usbtablet" as object first, and no other "special" objects, but the the generic event object as this is enough.
you may want to take a look at http://www.frogmouth.net/hid-doco/x401.html there you can see the input_event structure, and that is the only data you get from the event interface. that is :
struct input_event { struct timeval time; unsigned short type; unsigned short code; unsigned int value; };
for mouse movement, it could be like type=EV_REL, code=REL_X, value=85 ... for a tablet it could be type=EV_ABS, code=ABS_Y, value=19282 .... or for a keybpard type=EV_KEY, code=KEY_SPACE, value=0 .... or for the mouse wheel type=EV_REL, code=REL_WHEEL, value=12 ....
as you can see, you have only 3 outlets, or four if you want to have the timestamp as well.
it should be really easy to decode that output in a patch by route or select. that avoids the redundancy of having multiple binary objects for more or less the same function. and, you dont need to add the input devices anywhere to access them, like with xinput. its simply a device file, thats it ...
greets,
chris
zen
\
\
\[D[D[D[D