[PD] [hid] users poll

IOhannes m zmoelnig zmoelnig at iem.at
Fri Jun 24 19:33:55 CEST 2005

Hans-Christoph Steiner wrote:
> On Jun 23, 2005, at 12:21 PM, IOhannes m zmoelnig wrote:

>>> abs_throttle, key_b, does give you more info than 0, 6, 48.  Having
btw, have i ever said something contrary to this ?

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

yep, mea culpa.

> just look at the output of the hid object.  Have you even used [hid]?

yes i surely did.
but i have to admit, that its interface keeps from using it more often.
i just do not see, why i need a message "rel rel_x 12" instead of "rel x
12" which provides exactly the same amount of information.

it is exactly the problem of usability: i as a user just do not really
like to use these objects because they seem to do things "the wrong way".
this is bad, because i really think that the attempt of unifying
HID-input over all platforms is great. i do think it should be used
whenever people want to interact with hid's to produce re-usable code.
but it makes me sad that i _do not want_ to use those objects because of
usability issues.

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

i do not really get you point here.

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

while i don't think it adds much to flexibility, i can understand your
point here a bit.

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

now that i have read it, i say "so what?"
unfortunately your did not add any insights into this theme.
(so either i am that stupid or i already got the great picture; i tend
to prefer the latter)

i guess these are the relevant parts:

"The final [hid] toolkit scheme is a modified version of the
Linux scheme. The Linux scheme has some aspects of it
that are too specific, making it hard to abstract, i.e. button
names for each device type, rather than just button numbers.
While some parts of the scheme seem redundant. For
example relative axes have a ”rel” event type and ”rel_x”,
”rel_y”, etc. as event codes . This redundancy provides more
flexibility while directly reflecting the data as delivered from
the operating system. Symbolic names rather than numbers
were chosen for the elements because usability was a key design
concern, and most people find symbolic labels easier to
remember than numeric labels. While there are some obvious
disadvantages to symbolic labels in this context, such as
increased CPU usage, none were severe enough to force the
need for numeric labels."

just claiming that "this redundancy provides more flexibility" does not
convince me a bit of its truth.
furthermore, "Symbolic names rather than numbers
were chosen for the elements because usability was a key design
concern, and most people find symbolic labels easier to
remember than numeric labels" can only be valid if you compare
"FireButton" with "92".
please show me that majority of people who tend to remember "but5"
easier than "button 5". (apart from orthographic issues)

and more:
"One key advantage of the button numbering
scheme is that it allows buttons on one device to work
in patches written for other devices."

i couldn't have said it in better words.

> 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 

i am talking about tiny modifications not about a complete review and
redesign of your library.
to implement these modifications will probably cost you less time than
we have used right now to discuss (or call it "flame", or "mock") this

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

i feared that you would be going to say something like that.
you missed my point: i was talking about the concept of hierarchical
messages and not about the delimiter to use.
i do not use OSC either (at least not on a very regular basis), and i
also would hate a dependency on OSC just for such feature.
my idea would be to rather use " " as the delimiter instead of "/", in
order to acchieve the same with [route].


for me, the biggest problem with people who are concerned about
"usability" is, that they often tend to know best what is "usable" while
ignoring my comments as being nerdish tech talk, not relevant to such
discussion, but cynical at best. of course this hurts my ego.

More information about the Pd-list mailing list