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@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
\[D[D[D[D
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
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@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@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
\[D[D[D[D
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
zen
\
\
\[D[D[D[D
Good point,
I think the less externals that duplicate functionality the better.
I'm very glad you are going for cross-platform.
I know very little about the hid interfaces, so my view is utterly from a user perspective (a user that already relies many different externals!)
What about an object that uses a creation argument to drive the type of input device. 1 for mouse, 2 for joystick for example. then the outlets are created based on the creation argument, according the number of dimensions of the device.
Then the abstraction just takes care of setting the type of device and routing the outlet appropriatly. (if you even need an abstraction at this level)
Just some more ideas.
B
On Wednesday, April 9, 2003, at 08:15 PM, Hans-Christoph Steiner wrote:
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@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@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
\[D[D[D[D
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
zen
\[D[D[D[D
-
bbogart -
bbogart＠ryerson.ca
-
Hans-Christoph Steiner