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".
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"
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.
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)
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"
mfg.asd.r IOhannes
PS. i hope to be able to read your paper by tomorrow.