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
evenyep, 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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list