[PD] [hid] users poll

[Hans-Christoph Steiner]

On Jun 22, 2005, at 4:26 AM, IOhannes m zmoelnig wrote:

> Mathieu Bouchard wrote:
>> On Fri, 17 Jun 2005, Hans-Christoph Steiner wrote:
>>> On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
>>>
>> Right. Having them wired the other way around would be quite  
>> counterproductive.
>
> thanks matju, this mail is really a good laugh.

You two do seem to like to mock people, which I think is  
counterproductive at best.

>> 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
>
> how do you justify GridFlow being an "abnormal" use ?
> what makes you sure that others do not use pd in even more abnormal,  
> bizarre and pervert ways ?
>
>
>> 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.
>
> btw, i totally agree to matju about this.
> when i first heard of [hid] i thought: "wow cool, finally something  
> that gives me a generic interface to (hi) devices of any kind. i do  
> not have to bother about the specifics of the device any more"
> then it turned out to have weird names like "but1", "but2", "but3"  
> which does not give me _any more_ information than simple numbers "1"  
> "2" "3"  would have done (actually i would prefer lists "button 1"  
> "button 2",...)

btn_1, btn_2, does not give you more info that 1, 2, but rel_x,  
abs_throttle, key_b, does give you more info than 0, 6, 48.  Having  
mixed float/symbol data coming out of [hid] would be a nightmare to  
handle in Pd, so I chose to use only one atom type.

I appreciate feedback on this event scheme, but first you have to  
understand the whole picture for it to be helpful.  It is outlined in  
my paper on the topic.  This paper answers your above question, for  
example.

http://hct.ece.ubc.ca/nime/2005/proc/nime2005_140.pdf


> i think, that one should use symbolic identifiers (in pd) iff we have  
> a fixed (finite) set of symbolic names (like "button" and "axis");  
> probably it is a bad habit to try to abbreviate these symbolic names  
> for the sake of less typing. "but5", "head6", "while7", "ass8"

There are a fixed, finite set of symbols, they are derived from the USB  
HID spec.

> otoh, sets that are likely to be extended (indeterminate sets) should  
> rather be represented by numeric values.

They are, but with types prepended to keep everything as symbol atoms,  
e.g. key_253, abs_54, btn_1, etc.

> a human can fairly well interprete "but1" as the "first button", and  
> "axis8" as the "eighth axis" (btw: how do you write 8th ?)

eighth is correct, strange as it looks.

> but a human can equally well interprete "button 1" as the 1st button  
> and "axis 8" as the 8th axis.
> computers will have a hard time with "axis8" while "button 1" is far  
> simpler to parse for them.

[route] parses abs_x, btn_1, etc. just fine.  So far, I haven't seen  
[hid] data handling that can't be solved using [route] as the first  
step.

> matju: please ignore or correct my blasphemies on set theory.
>
>
> input devices in the past had (maybe) a tendency to be  
> computer-centric, probably ignoring human needs.
> with the advent of hid, the focus has been shifted towards the humans.  
> i do not think that this justifies the ignorance of computer needs.

Computers have feelings too! ;)  Please show me an example patch of  
where the [hid] symbols cause problems that have no reasonable  
workaround.

.hc


>>> What is [listfind] and [atof] anyway?
>> [listfind] is an external I wrote sometime ago to find the index of a  
>> symbol in a list. [atof] is an external I wrote the other day to pick  
>> up the first float-looking portion of a symbol and turn it to a  
>> float; I posted the source code of the latter on pd-list recently. Do  
>> you know any objects that already achieve that?
>
> well, if you only care for integers, there is [atoi]
> if you care for floats, you can abuse [symbol2list]
>
>
>
>
> mfg.as.dr
> IOhannes
>
>

________________________________________________________________________ 
____

If you are not part of the solution, you are part of the problem.
                                                                          
                            - Eldridge Cleaver
-------------- 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/547eab71/attachment.bin>