[PD] wacom usb tablet as controller ?

[Hans-Christoph Steiner]

The problem here, correct me if I'm wrong, is that you would then need to
have different abstractions for each platform, since the various event
interfaces are different.  Then the patches built with this system would
be platform-specific.  Unless there was a cross-platform event object that 
hides the differences.

.hc

On Wed, 9 Apr 2003 bbogart at ryerson.ca wrote:

> 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
> > 
> 

	zen
	   \
	    \
	     \