[PD] [hid] users poll

Hans-Christoph Steiner hans at eds.org
Fri Jun 17 18:03:01 CEST 2005


On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:

> On Wed, 15 Jun 2005, Hans-Christoph Steiner wrote:
>> On Jun 15, 2005, at 1:23 PM, Mathieu Bouchard wrote:
>>> I think that as long as integers still can be used, there is no  
>>> problem with supporting symbols. I mean I've seen cases where the  
>>> enforcing of symbols means having to use [sprintf] all over the  
>>> place in a less-than-elegant way.
>> Integers/floats are not supported in [hid] because that would defeat  
>> one of the main purposes that inspired me to write it: to have a  
>> clean, straightforward API.
>
> Woops, I had thought only about messages sent to HID (e.g.  
> steppermotors controlled by HID, or forcefeedback joystick). See below  
> for input messages.
>
>> For example, you probably won't need to use a lookup table to  
>> understand [route abs_x abs_y abs_throttle] but most people would  
>> need it for [route 1 3 14].
>
> 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.  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.  "in4" is not a very meaningful label, HID implementations  
generally use more descriptive names like "abs_x", "rel_rz".  I don't  
have my multI/O running yet, so I haven't tested a "Multi-Axis  
Controller" with [hid] yet, that might change my perspective.

As for the [gate 7] option, you could just [route abs_x abs_y abs_z] to  
[gate 3] for example. I've never heard of [shunt]

>> [sprintf] with [hid] data, but please try out strange, unorthodox  
>> configurations
>
> Using the same example above, if I want to build an array using values  
> from the seven sensors, so that the shape of an object (as "seen" by  
> the sensors) can be visualized, is there no better means than using a  
> big route and a bunch of messageboxes ? If the sensor id is an  
> integer, then I can just use one single object: [tabwrite myarray].  
> (or [s myarray])
>
> 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.  So other methods would be more efficient  
for large arrays of sensors.  I never claimed this would work great for  
all situations, but it will still work for the above situation.  What  
is [listfind] and [atof] anyway?

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.  You can do everything that you need to using Miller's Pd and  
the [hid] object.  The rest of the [hid] toolkit objects are written in  
Pd (i.e. abstractions).

>>> Actually comparing symbols is much faster than comparing floats, if  
>>> you run Pd on a 386 or on a PDA.
>> That good to know. I was thinking strcmp() versus ==.
>
> Sorry, actually a float == can be optimised back to the same as int  
> ==. It depends on whether the compiler knows about it (or else you are  
> running a FPU emulator and it's certainly much slower)
>
>> So comparing symbols in Pd is basically a == operation using the  
>> pointer integers, right?
>
> yes.
>
>> If you ever feel like checking out my [hid] code, matju, I'd love  
>> advice on optimization.  Since it can run up to once every 1ms,  
>> optimization is key.
>
> depends on how many 386's with USB you use =)
>
> how common is USB on PDA's ?

Not uncommon.  The Sharp Zaurus series, for example, can act as a USB  
host.  I am probably going to get one, so maybe I'll be using [hid]  
with it then...

.hc

________________________________________________________________________ 
____


"Computer science is no more related to the computer than astronomy is  
related to the telescope."
                                                                          
                                -Edsger Dykstra





More information about the Pd-list mailing list