[PD] [hid] users poll

Hans-Christoph Steiner hans at eds.org
Thu Jun 23 19:52:46 CEST 2005

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.


> 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  

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

More information about the Pd-list mailing list