[PD] [hid] users poll

[IOhannes m zmoelnig]

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".


> 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"


> 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)


>> 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"


mfg.asd.r
IOhannes

PS. i hope to be able to read your paper by tomorrow.