[PD] wacom usb tablet as controller ?

[bbogart at ryerson.ca]

I think the more generic object makes more sense, the most flexible that works with multiple devices.
For the end user experience (wanting each axis come out of a different outlet) Then a a set of abstractions for those devies using the generic object could be made. 

Still have a "tablet" object, acts just the same way, but can easy be changed (at the patch level) to a mouse object...

 my 2 cents.

B.

----- Original Message -----
From: Hans-Christoph Steiner <hans at eds.org>
Date: Wednesday, April 9, 2003 11:14 am
Subject: Re: [PD] wacom usb tablet as controller ?

> 
> You misunderstood the kind of object I am building.  Look at J. 
> Sarlo'sjoystick 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
>           \
>            \
>             \
> 
> 
> _______________________________________________
> PD-list mailing list
> PD-list at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
>