[PD] [hid] users poll

[Hans-Christoph Steiner]

On Jun 23, 2005, at 12:21 PM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> You two do seem to like to mock people, which I think is   
>> counterproductive at best.
>
> yep.
>
>> 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
> why can't you have a hierarchical structure like "rel x" ? this would  
> allow 1 route to distinguish between "rel"ative and "abs"olute, and  
> another [route] to distinguish between "x" and "y".

Um... RTFM?  Check out hid-help.pd, that is already the case.  Or even  
just look at the output of the hid object.  Have you even used [hid]?


>> 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.
>
> what makes you think that mixing numbers and symbols are a nightmare ?
> this might sound stupid (please do not reply: "indeed you sound  
> stupid"), but you are already mixing symbols and floats: "rel_x 12"

the way it is:
[rel rel_x 12(  is an undefined set of atoms
[rel_x 12( is an undefined set of atoms
[12( is a "float"

What you propose:
[rel rel_x 12(  is an undefined set of atoms
[0 12( is an "list"
[12( is a "float"

IMHO, I think its more flexible to keep the sets the same format.


>
>
>> 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 am just printing it...
>
>
>>> 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.
>
> ouch. this was the whole point of matjus argument. why fix the number  
> of indefinite sets by arbitrary choices (even if they have been made  
> upstream)

Because that is a much bigger problem that writing an HID object.   
That's what they did with the Linux input system, its a wonderful  
thing.  But I want to have something that works now, not in a few  
years.  That's how long it took with the Linux input system, with at  
least one full time programmer paid by SuSE to work on it.  I am  
currently not paid to do this.  If you pay me a decent salary for a  
year, I'll write a better, more general system.

>>> 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.
>
> now i understand your feeling about mixing symbols and floats better:  
> they _are_ a nightmare.
>
> (i am not trying to ridicule or mock anyone)
>
>
>>> 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.
>
> thanks.
>
>>> 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.
>
> well yes: why don't we choose to output the values of the x axis as  
> symbols to: like "axis8_12"; then use [route] to discriminate between  
> axis8_12 and axis8_13.5
>
>
>>> 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
> all right.
> i was thinking about the poor programmers.
>
>
>
>
>
> seriously, preprocessor-defines have no way of expressing things as  
> lists.
> they are good because programmers do not have to remember weird values.
> they are bad because the reduce structured data ("axis 1, relative  
> change") to unstructured symbols.
>
> i am not sure, whether a hinterface should mimick this behaviour.
>
> probably we should have a look over the rim of our worlds, into the  
> neighbourhood galaxy of OSC.
> why do you think they introduced hierarchical selectors like  
> "foo/bar/joey".
> modern parsers could do as well handle "foobarjoey"

Then you can't use basic Pd objects like [route], you would need  
special objects like [OSCroute].  I don't use OSC and don't want to be  
forced to in order to program in Pd.

.hc



>
>
> mfg.asd.r
> IOhannes
>
> PS. i hope to be able to read your paper by tomorrow.
>
>
>
>

________________________________________________________________________ 
____

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.
Now that he can realize them, he must either change them, or perish.
		                                                -William Carlos  
Williams

-------------- 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/dd50fc8a/attachment.bin>