[PD] [hid] users poll

[Hans-Christoph Steiner]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2353 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050623/2ad492ca/attachment.bin>