[PD] [hid] users poll

[vade]

You know, downloading these emails seems to be a waste of bandwidth.  
This seems like a value based discussion rather than an 'empirical  
one is provably better than the other' discussion...

Dont like HID? Dont use it.

Want to change it? Grab the source.

peace++;

-// vad3'

On Jun 24, 2005, at 1:33 PM, IOhannes m zmoelnig wrote:

> 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:
>
> quoting:
> "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
> problem.
>
>
>>> 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].
>
>
>
> mfg,.asdf.
> IOhannes
>
>
> 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.
>
>
>
>
>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list
>