What's with the attitude? Its a waste of all of our time to have some
flame war, especially when your criticisms are based on
misunderstandings and your situation is at the very far extremes of the
USB HID spec and pretty much outside of the realm that USB HID was
designed for. For example, the Linux input event system does not allow
more than 64 absolute axes, and only half of those axes are even
defined. [hid] aims to support that spec, not every input possibility
under the sun, but I think it can work for you without too much hassle.
It seems to me that you are saying that I should tailor [hid] to work
for every single input possibility. That would greatly impair the
usability for almost everyone else who is going to use it. What you
are trying to do with your array of sensors is barely in the realm of
USB HID. This is not defined by me, this was defined by the USB
organization.
USB HID is about mice, joysticks, tablets, gamepads, etc. There is no
USB device type "64 range finders in a row". The USB HID spec is a
perfect example of design by company getting their little piece custom
piece in. Its way too big, and its not pretty. For example, UPSs
(Uninterruptible Power Supplies) are part of USB HID. With [hid], I am
trying to make it accessible, but also, to add a certain amount of
flexibility in keeping with what makes Pd great. I outline this idea
in this paper (http://hct.ece.ubc.ca/nime/2005/proc/nime2005_140.pdf
), but will happily answer further questions on this list.
On Jun 22, 2005, at 1:01 AM, Mathieu Bouchard wrote:
On Fri, 17 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
however if I have a row of 7 distance sensors, such as what is being
used by 13 artists at Vidéographe this month, [gate 7] or [shunt 7]
is more straightforward than [route in1 in2 in3 in4 in5 in6 in7].
(The sensor box most likely wouldn't have any meaningful labels at
all for those axes; is it possible that they wouldn't have labels at
all? what happens in this case?)If you are using HID, then you are talking about Human Interface
Devices, which can be broken down into buttons and axes.Cool! I am also talking about buttons and axes. I guess I'm on the
right track.If you are building your own, then I highly recommend that you map
sensors which provide continuous data to axis types and on/off
sensors to button/key types.Right. Having them wired the other way around would be quite
counterproductive."in4" is not a very meaningful label, HID implementations generally
use more descriptive names like "abs_x", "rel_rz".What's the link between these labels and what you have just said about
humans and axes and buttons? It has something to do with "I am not a
number! I am a free man!", yes? Humans don't like to be treated like
numbers, so if [hid] is to interface with a Human, it has to be
through a label. It's diplomacy and it's symbolism.
I don't have my multI/O running yet,
Is it sufficient that it respect the USB-HID protocol for it to
qualify as Human Interface, or does it have to name axes?
You're missing the point here. If something respects the USB HID spec,
then it has specific IDs for specific elements. These elements are
defined as part of the spec. The USB HID spec names standard elements
with standard IDs. So the x and y axes on every USB HID "Joystick" and
USB HID "Gamepad", for example, are defined as kHIDUsage_GD_X and
kHIDUsage_GD_Y in MacOSX/C; ABS_X and ABS_Y in Linux/C; or, abs_x and
abs_y in Pd/[hid].
In C, this is done using #defines which are mapped to integers. So
when you are programming in C, you don't need to remember those
integers, you use the #defines, which are easy to read symbols, like
kHIDUsage_GD_X, kHIDUsage_GD_Ry, kHIDUsage_GD_Slider, or
kHIDUsage_GD_Wheel (MacOSX); or ABS_X, ABS_RY, ABS_THROTTLE,
ABS_WHEEL(Linux). I think we can use symbols in Pd also, plus there is
the added benefit of being more efficient to compare (as you, Matju,
helpfully outlined). In [hid], symbols such as abs_x, abs_ry,
abs_throttle, abs_wheel are derived from the Linux names, which are in
turn derived from USB HID.
so I haven't tested a "Multi-Axis Controller" with [hid] yet, that
might change my perspective.That's another thing I wonder about. How many axes does it take before
something becomes "Multi-Axis" ?
"Multi-Axis Controller" is defined in USB HID, like like "Mouse",
"Joystick", "GamePad", "Keyboard", etc. etc. If you want to know
exactly how its defined, I suggest you RTFM.
As for the [gate 7] option, you could just [route abs_x abs_y abs_z]
to [gate 3] for example.I don't understand. I'm not talking about abs_x abs_y abs_z, I'm
talking about a row of seven distance sensors parallel to each other.
Should I name them abs_z1 abs_z2 abs_z3 abs_z4 abs_z5 abs_z6 abs_z7 ?
See above about how USB HID defines element IDs.
I've never heard of [shunt]
It's just the same as [demux] or [gate], really, but it's compatible
with jMax's [demux].If I have really a lot of sensors, I could instead use [for 0 64 1]
-> [sprintf in%d] -> [listfind], or I could use [atof] (that I
posted a few days ago).This is really not HID stuff. The vast majority of HIDs have 4 or
less axes and 8 or less buttons.Ok, so human interfaces that are made with axes are not human if they
have too many axes?
Ask the USB people, they defined it.
Sounds to me that you like you work in your own specific ways:
[listfind], [atof], [shunt] for example. I am gearing [hid] to
normal Pd use.Wow. It's not about liking to work in my own specific ways. It's about
finding ways to circumvent [hid]'s symbol restriction so that I don't
need to copypaste. If I don't have access to abnormal Pd use (that is,
GridFlow), then I just have to do [route abs_z1 abs_z2 abs_z3 abs_z4
abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13
abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21
abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29
abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37
abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45
abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53
abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61
abs_z62 abs_z63]. That's more like a normal human Pd patch.
I should explain what I meant more. Personally, I'd like to see Pd
programming stay within Pd, instead of being made up of objects written
in C. I think Pd has the potential to be a programming platform in its
own right, rather than just a bunch of objects written in C. I think
this problem at hand can be solved within Pd without too much grief.
But, of course, you are free to do things however you choose. You can
even hack you're own version of [hid] if you want.
This is an extreme situation, so it won't be the most attractive
solution, but if you chain [route]s in abstractions, it becomes quite
manageable. For example:
[route abs_x abs_y abs_z abs_rx abs_ry abs_rz]
|
[route abs_throttle
abs_rudder abs_wheel...]
Yes, this is not pretty, but you are trying to force the USB HID spec
to do something it wasn't designed to do, so its going to be ugly.
.hc
There is no way to peace, peace is the way.
-A.J. Muste