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. Havingwhy 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.pdfi 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.5input 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.
.hc
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
Williams