So now that there are some people using [hid], I want to ask a question
about how its working for people, specifically about the use of symbols
rather than integers for the event naming scheme (i.e. "abs" vs. "2";
"rel_rx" vs. "5", etc.). It definitely takes more CPU power to use
symbols, so I have two questions:
Do you notice the extra CPU load from [hid]?
Do you find the symbolic names useful, versus numbers?
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin
On Wed, 15 Jun 2005, Hans-Christoph Steiner wrote:
So now that there are some people using [hid], I want to ask a question about how its working for people, specifically about the use of symbols rather than integers for the event naming scheme (i.e. "abs" vs. "2"; "rel_rx" vs. "5", etc.). It definitely takes more CPU power to use symbols, so I have two questions: Do you notice the extra CPU load from [hid]? Do you find the symbolic names useful, versus numbers?
I think that as long as integers still can be used, there is no problem with supporting symbols. I mean I've seen cases where the enforcing of symbols means having to use [sprintf] all over the place in a less-than-elegant way.
Comparing symbols is fast. [route foo bar baz] is just as fast as [route 55 242 666]. This is because gensym() ensures that if two symbols refer to the same text then they necessarily have the same pointer value. This is a standard: LISP/Smalltalk/Ruby/etc all do it the same.
Actually comparing symbols is much faster than comparing floats, if you run Pd on a 386 or on a PDA.
Comparing strings would be slower but Pd doesn't have strings.
(I haven't used [hid] yet though.)
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
On Jun 15, 2005, at 1:23 PM, Mathieu Bouchard wrote:
On Wed, 15 Jun 2005, Hans-Christoph Steiner wrote:
So now that there are some people using [hid], I want to ask a
question about how its working for people, specifically about the use
of symbols rather than integers for the event naming scheme (i.e.
"abs" vs. "2"; "rel_rx" vs. "5", etc.). It definitely takes more CPU
power to use symbols, so I have two questions: Do you notice the extra CPU load from [hid]? Do you find the symbolic names useful, versus numbers?I think that as long as integers still can be used, there is no
problem with supporting symbols. I mean I've seen cases where the
enforcing of symbols means having to use [sprintf] all over the place
in a less-than-elegant way.
Integers/floats are not supported in [hid] because that would defeat
one of the main purposes that inspired me to write it: to have a clean,
straightforward API. For example, you probably won't need to use a
lookup table to understand [route abs_x abs_y abs_throttle] but most
people would need it for [route 1 3 14]. I can't think of anytime
where you'd need to use [sprintf] with [hid] data, but please try out
strange, unorthodox configurations and let me know if the symbol scheme
causes problems. Its an experiment, every HID API I have seen uses
integers, but almost all are aimed at people who think in terms of
struct, io_service_t, ioctl, etc.
I am planning on writing [darwinhid], [windowshid], and [linuxhid],
which will output the data straight from the OS, i.e. integers. Those
objects are for getting data from very esoteric devices, but I would
discourage using them for anything but the situations where [hid] would
not work.
Comparing symbols is fast. [route foo bar baz] is just as fast as
[route 55 242 666]. This is because gensym() ensures that if two
symbols refer to the same text then they necessarily have the same
pointer value. This is a standard: LISP/Smalltalk/Ruby/etc all do it
the same.Actually comparing symbols is much faster than comparing floats, if
you run Pd on a 386 or on a PDA.
That good to know. I was thinking strcmp() versus ==. That makes me
very happy. So comparing symbols in Pd is basically a == operation
using the pointer integers, right? I was thinking I needed to keep
these symbols as short as possible for efficiency's sake. Now I can
happily eliminate the unixy abbrvs:
syn = sync
snd = sound
msc = misc
rep = repeat
pwr = power
These would probably be too long tho:
abs = absolute
rel = relative
btn = button
ff = force_feedback
If you ever feel like checking out my [hid] code, matju, I'd love
advice on optimization. Since it can run up to once every 1ms,
optimization is key.
.hc
Comparing strings would be slower but Pd doesn't have strings.
(I haven't used [hid] yet though.)
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
On Wed, 15 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 15, 2005, at 1:23 PM, Mathieu Bouchard wrote:
I think that as long as integers still can be used, there is no problem with supporting symbols. I mean I've seen cases where the enforcing of symbols means having to use [sprintf] all over the place in a less-than-elegant way.
Integers/floats are not supported in [hid] because that would defeat one of the main purposes that inspired me to write it: to have a clean, straightforward API.
Woops, I had thought only about messages sent to HID (e.g. steppermotors controlled by HID, or forcefeedback joystick). See below for input messages.
For example, you probably won't need to use a lookup table to understand [route abs_x abs_y abs_throttle] but most people would need it for [route 1 3 14].
however if I have a row of 7 distance sensors, such as what is being used by 13 artists at Vidéographe this month, [gate 7] or [shunt 7] is more straightforward than [route in1 in2 in3 in4 in5 in6 in7]. (The sensor box most likely wouldn't have any meaningful labels at all for those axes; is it possible that they wouldn't have labels at all? what happens in this case?)
[sprintf] with [hid] data, but please try out strange, unorthodox configurations
Using the same example above, if I want to build an array using values from the seven sensors, so that the shape of an object (as "seen" by the sensors) can be visualized, is there no better means than using a big route and a bunch of messageboxes ? If the sensor id is an integer, then I can just use one single object: [tabwrite myarray]. (or [s myarray])
If I have really a lot of sensors, I could instead use [for 0 64 1] -> [sprintf in%d] -> [listfind], or I could use [atof] (that I posted a few days ago).
Actually comparing symbols is much faster than comparing floats, if you run Pd on a 386 or on a PDA.
That good to know. I was thinking strcmp() versus ==.
Sorry, actually a float == can be optimised back to the same as int ==. It depends on whether the compiler knows about it (or else you are running a FPU emulator and it's certainly much slower)
So comparing symbols in Pd is basically a == operation using the pointer integers, right?
yes.
If you ever feel like checking out my [hid] code, matju, I'd love advice on optimization. Since it can run up to once every 1ms, optimization is key.
depends on how many 386's with USB you use =)
how common is USB on PDA's ?
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
On Wed, 15 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 15, 2005, at 1:23 PM, Mathieu Bouchard wrote:
I think that as long as integers still can be used, there is no
problem with supporting symbols. I mean I've seen cases where the
enforcing of symbols means having to use [sprintf] all over the
place in a less-than-elegant way.Integers/floats are not supported in [hid] because that would defeat
one of the main purposes that inspired me to write it: to have a
clean, straightforward API.Woops, I had thought only about messages sent to HID (e.g.
steppermotors controlled by HID, or forcefeedback joystick). See below
for input messages.For example, you probably won't need to use a lookup table to
understand [route abs_x abs_y abs_throttle] but most people would
need it for [route 1 3 14].however if I have a row of 7 distance sensors, such as what is being
used by 13 artists at Vidéographe this month, [gate 7] or [shunt 7] is
more straightforward than [route in1 in2 in3 in4 in5 in6 in7]. (The
sensor box most likely wouldn't have any meaningful labels at all for
those axes; is it possible that they wouldn't have labels at all? what
happens in this case?)
If you are using HID, then you are talking about Human Interface
Devices, which can be broken down into buttons and axes. If you are
building your own, then I highly recommend that you map sensors which
provide continuous data to axis types and on/off sensors to button/key
types. "in4" is not a very meaningful label, HID implementations
generally use more descriptive names like "abs_x", "rel_rz". I don't
have my multI/O running yet, so I haven't tested a "Multi-Axis
Controller" with [hid] yet, that might change my perspective.
As for the [gate 7] option, you could just [route abs_x abs_y abs_z] to
[gate 3] for example. I've never heard of [shunt]
[sprintf] with [hid] data, but please try out strange, unorthodox
configurationsUsing the same example above, if I want to build an array using values
from the seven sensors, so that the shape of an object (as "seen" by
the sensors) can be visualized, is there no better means than using a
big route and a bunch of messageboxes ? If the sensor id is an
integer, then I can just use one single object: [tabwrite myarray].
(or [s myarray])If I have really a lot of sensors, I could instead use [for 0 64 1] ->
[sprintf in%d] -> [listfind], or I could use [atof] (that I posted a
few days ago).
This is really not HID stuff. The vast majority of HIDs have 4 or less
axes and 8 or less buttons. So other methods would be more efficient
for large arrays of sensors. I never claimed this would work great for
all situations, but it will still work for the above situation. What
is [listfind] and [atof] anyway?
Sounds to me that you like you work in your own specific ways:
[listfind], [atof], [shunt] for example. I am gearing [hid] to normal
Pd use. You can do everything that you need to using Miller's Pd and
the [hid] object. The rest of the [hid] toolkit objects are written in
Pd (i.e. abstractions).
Actually comparing symbols is much faster than comparing floats, if
you run Pd on a 386 or on a PDA.That good to know. I was thinking strcmp() versus ==.
Sorry, actually a float == can be optimised back to the same as int
==. It depends on whether the compiler knows about it (or else you are
running a FPU emulator and it's certainly much slower)So comparing symbols in Pd is basically a == operation using the
pointer integers, right?yes.
If you ever feel like checking out my [hid] code, matju, I'd love
advice on optimization. Since it can run up to once every 1ms,
optimization is key.depends on how many 386's with USB you use =)
how common is USB on PDA's ?
Not uncommon. The Sharp Zaurus series, for example, can act as a USB
host. I am probably going to get one, so maybe I'll be using [hid]
with it then...
.hc
"Computer science is no more related to the computer than astronomy is
related to the telescope."
-Edsger Dykstra
On Fri, 17 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
however if I have a row of 7 distance sensors, such as what is being used by 13 artists at Vidéographe this month, [gate 7] or [shunt 7] is more straightforward than [route in1 in2 in3 in4 in5 in6 in7]. (The sensor box most likely wouldn't have any meaningful labels at all for those axes; is it possible that they wouldn't have labels at all? what happens in this case?)
If you are using HID, then you are talking about Human Interface Devices, which can be broken down into buttons and axes.
Cool! I am also talking about buttons and axes. I guess I'm on the right track.
If you are building your own, then I highly recommend that you map sensors which provide continuous data to axis types and on/off sensors to button/key types.
Right. Having them wired the other way around would be quite counterproductive.
"in4" is not a very meaningful label, HID implementations generally use more descriptive names like "abs_x", "rel_rz".
What's the link between these labels and what you have just said about humans and axes and buttons? It has something to do with "I am not a number! I am a free man!", yes? Humans don't like to be treated like numbers, so if [hid] is to interface with a Human, it has to be through a label. It's diplomacy and it's symbolism.
I don't have my multI/O running yet,
Is it sufficient that it respect the USB-HID protocol for it to qualify as Human Interface, or does it have to name axes?
so I haven't tested a "Multi-Axis Controller" with [hid] yet, that might change my perspective.
That's another thing I wonder about. How many axes does it take before something becomes "Multi-Axis" ?
As for the [gate 7] option, you could just [route abs_x abs_y abs_z] to [gate 3] for example.
I don't understand. I'm not talking about abs_x abs_y abs_z, I'm talking about a row of seven distance sensors parallel to each other. Should I name them abs_z1 abs_z2 abs_z3 abs_z4 abs_z5 abs_z6 abs_z7 ?
I've never heard of [shunt]
It's just the same as [demux] or [gate], really, but it's compatible with jMax's [demux].
If I have really a lot of sensors, I could instead use [for 0 64 1] -> [sprintf in%d] -> [listfind], or I could use [atof] (that I posted a few days ago).
This is really not HID stuff. The vast majority of HIDs have 4 or less axes and 8 or less buttons.
Ok, so human interfaces that are made with axes are not human if they have too many axes?
Sounds to me that you like you work in your own specific ways: [listfind], [atof], [shunt] for example. I am gearing [hid] to normal Pd use.
Wow. It's not about liking to work in my own specific ways. It's about finding ways to circumvent [hid]'s symbol restriction so that I don't need to copypaste. If I don't have access to abnormal Pd use (that is, GridFlow), then I just have to do [route abs_z1 abs_z2 abs_z3 abs_z4 abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13 abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21 abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29 abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37 abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45 abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53 abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61 abs_z62 abs_z63]. That's more like a normal human Pd patch.
What is [listfind] and [atof] anyway?
[listfind] is an external I wrote sometime ago to find the index of a symbol in a list. [atof] is an external I wrote the other day to pick up the first float-looking portion of a symbol and turn it to a float; I posted the source code of the latter on pd-list recently. Do you know any objects that already achieve that?
You can do everything that you need to using Miller's Pd and the [hid] object.
Sounds like Steve's Music Store's Slogan: If we don't have it, you don't need it!
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
Mathieu Bouchard wrote:
On Fri, 17 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
Right. Having them wired the other way around would be quite counterproductive.
thanks matju, this mail is really a good laugh.
Wow. It's not about liking to work in my own specific ways. It's about finding ways to circumvent [hid]'s symbol restriction so that I don't need to copypaste. If I don't have access to abnormal Pd use (that is, GridFlow), then I just have to do [route abs_z1 abs_z2 abs_z3 abs_z4
how do you justify GridFlow being an "abnormal" use ? what makes you sure that others do not use pd in even more abnormal, bizarre and pervert ways ?
abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13 abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21 abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29 abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37 abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45 abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53 abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61 abs_z62 abs_z63]. That's more like a normal human Pd patch.
btw, i totally agree to matju about this. when i first heard of [hid] i thought: "wow cool, finally something that gives me a generic interface to (hi) devices of any kind. i do not have to bother about the specifics of the device any more" then it turned out to have weird names like "but1", "but2", "but3" which does not give me _any more_ information than simple numbers "1" "2" "3" would have done (actually i would prefer lists "button 1" "button 2",...)
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"
otoh, sets that are likely to be extended (indeterminate sets) should rather be represented by numeric values.
a human can fairly well interprete "but1" as the "first button", and "axis8" as the "eighth axis" (btw: how do you write 8th ?) 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.
matju: please ignore or correct my blasphemies on set theory.
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.
What is [listfind] and [atof] anyway?
[listfind] is an external I wrote sometime ago to find the index of a symbol in a list. [atof] is an external I wrote the other day to pick up the first float-looking portion of a symbol and turn it to a float; I posted the source code of the latter on pd-list recently. Do you know any objects that already achieve that?
well, if you only care for integers, there is [atoi] if you care for floats, you can abuse [symbol2list]
mfg.as.dr IOhannes
On Jun 22, 2005, at 4:26 AM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Fri, 17 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
Right. Having them wired the other way around would be quite
counterproductive.thanks matju, this mail is really a good laugh.
You two do seem to like to mock people, which I think is
counterproductive at best.
Wow. It's not about liking to work in my own specific ways. It's
about finding ways to circumvent [hid]'s symbol restriction so that I
don't need to copypaste. If I don't have access to abnormal Pd use
(that is, GridFlow), then I just have to do [route abs_z1 abs_z2
abs_z3 abs_z4how do you justify GridFlow being an "abnormal" use ? what makes you sure that others do not use pd in even more abnormal,
bizarre and pervert ways ?abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13
abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21
abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29
abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37
abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45
abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53
abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61
abs_z62 abs_z63]. That's more like a normal human Pd patch.btw, i totally agree to matju about this. when i first heard of [hid] i thought: "wow cool, finally something
that gives me a generic interface to (hi) devices of any kind. i do
not have to bother about the specifics of the device any more" then it turned out to have weird names like "but1", "but2", "but3"
which does not give me _any more_ information than simple numbers "1"
"2" "3" would have done (actually i would prefer lists "button 1"
"button 2",...)
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
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.
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 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.
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.
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.
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.
matju: please ignore or correct my blasphemies on set theory.
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
where the [hid] symbols cause problems that have no reasonable
workaround.
.hc
What is [listfind] and [atof] anyway?
[listfind] is an external I wrote sometime ago to find the index of a
symbol in a list. [atof] is an external I wrote the other day to pick
up the first float-looking portion of a symbol and turn it to a
float; I posted the source code of the latter on pd-list recently. Do
you know any objects that already achieve that?well, if you only care for integers, there is [atoi] if you care for floats, you can abuse [symbol2list]
mfg.as.dr IOhannes
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13
abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21
abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29
abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37
abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45
abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53
abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61
abs_z62 abs_z63]. That's more like a normal human Pd patch.
There are a fixed, finite set of symbols, they are derived from the USB
HID spec.
sorry didnt read this whole thread, but why are they symbols and not lists? this almost necessitates regex, and we all know how well that works in PD...
c
They are, but with types prepended to keep everything as symbol atoms,
e.g. key_253, abs_54, btn_1, etc.
On Jun 23, 2005, at 12:06 PM, ix@replic.net wrote:
abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13 abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21 abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29 abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37 abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45 abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53 abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61 abs_z62 abs_z63]. That's more like a normal human Pd patch.
There are a fixed, finite set of symbols, they are derived from the
USB HID spec.sorry didnt read this whole thread, but why are they symbols and not
lists? this almost necessitates regex, and we all know how well that
works in PD...
event types and event IDs are symbols, the data is a float. The whole
event is a set of atoms:
[abs abs_x 114(
[key key_q 1(
A set of atoms that begins with a float is defined as a "list" in Pd.
A set of atoms that begins with a symbol is undefined. Try out
hid-help.pd and it will be clearer, there are numerous examples there.
.hc
c
They are, but with types prepended to keep everything as symbol atoms, e.g. key_253, abs_54, btn_1, etc.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
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
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.
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
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.pdfi 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.
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
On Fri, 24 Jun 2005, IOhannes m zmoelnig wrote:
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.
The biggest problem with usability is that it's a particularly subjective aspect of software. One man's sidekick is another man's hurdle; one man's clarity is another man's confusion.
In practice it tends to become political, polarized between two types of people: power users versus casual users... or other similar axes of dissention.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
On Wed, 22 Jun 2005, IOhannes m zmoelnig wrote:
how do you justify GridFlow being an "abnormal" use ? what makes you sure that others do not use pd in even more abnormal, bizarre and pervert ways ?
Just abnormal relatively to Hans' expectations about normal uses. I didn't claim any exclusivity in the iconoclastic-abnormal-idiosyncrasy department. In fact, I can see that a lot of artists with ambition want abnormal things, and I already have been offered (a few days ago) to work on a project involving many more axes than the seven that we have at Videographe (e.g. possibly 20 or 40 or 64).
the 8th axis. computers will have a hard time with "axis8" while "button 1" is far simpler to parse for them.
I'd rather say it like this: it's easy for the computer to parse "axis8" but it may be hard for users to instruct the computer how to do it... especially if they don't have access to regexp-matching capabilities (I really should add that one as a standard GridFlow object...)
matju: please ignore or correct my blasphemies on set theory.
You didn't make any statements about set theory. I don't think that in itself this fact constitutes a blasphemy. :-)
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 don't need much. It's all about the users. As the users want more and more power, they are more and more like programmers. That is, programmers are merely power-power-power-users. A lot of that power is generated by automatability of tasks. The more easily and succinctly you can instruct the computer to perform a task on its own, the more power you have.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
What's with the attitude? Its a waste of all of our time to have some
flame war, especially when your criticisms are based on
misunderstandings and your situation is at the very far extremes of the
USB HID spec and pretty much outside of the realm that USB HID was
designed for. For example, the Linux input event system does not allow
more than 64 absolute axes, and only half of those axes are even
defined. [hid] aims to support that spec, not every input possibility
under the sun, but I think it can work for you without too much hassle.
It seems to me that you are saying that I should tailor [hid] to work
for every single input possibility. That would greatly impair the
usability for almost everyone else who is going to use it. What you
are trying to do with your array of sensors is barely in the realm of
USB HID. This is not defined by me, this was defined by the USB
organization.
USB HID is about mice, joysticks, tablets, gamepads, etc. There is no
USB device type "64 range finders in a row". The USB HID spec is a
perfect example of design by company getting their little piece custom
piece in. Its way too big, and its not pretty. For example, UPSs
(Uninterruptible Power Supplies) are part of USB HID. With [hid], I am
trying to make it accessible, but also, to add a certain amount of
flexibility in keeping with what makes Pd great. I outline this idea
in this paper (http://hct.ece.ubc.ca/nime/2005/proc/nime2005_140.pdf
), but will happily answer further questions on this list.
On Jun 22, 2005, at 1:01 AM, Mathieu Bouchard wrote:
On Fri, 17 Jun 2005, Hans-Christoph Steiner wrote:
On Jun 16, 2005, at 7:18 PM, Mathieu Bouchard wrote:
however if I have a row of 7 distance sensors, such as what is being
used by 13 artists at Vidéographe this month, [gate 7] or [shunt 7]
is more straightforward than [route in1 in2 in3 in4 in5 in6 in7].
(The sensor box most likely wouldn't have any meaningful labels at
all for those axes; is it possible that they wouldn't have labels at
all? what happens in this case?)If you are using HID, then you are talking about Human Interface
Devices, which can be broken down into buttons and axes.Cool! I am also talking about buttons and axes. I guess I'm on the
right track.If you are building your own, then I highly recommend that you map
sensors which provide continuous data to axis types and on/off
sensors to button/key types.Right. Having them wired the other way around would be quite
counterproductive."in4" is not a very meaningful label, HID implementations generally
use more descriptive names like "abs_x", "rel_rz".What's the link between these labels and what you have just said about
humans and axes and buttons? It has something to do with "I am not a
number! I am a free man!", yes? Humans don't like to be treated like
numbers, so if [hid] is to interface with a Human, it has to be
through a label. It's diplomacy and it's symbolism.
I don't have my multI/O running yet,
Is it sufficient that it respect the USB-HID protocol for it to
qualify as Human Interface, or does it have to name axes?
You're missing the point here. If something respects the USB HID spec,
then it has specific IDs for specific elements. These elements are
defined as part of the spec. The USB HID spec names standard elements
with standard IDs. So the x and y axes on every USB HID "Joystick" and
USB HID "Gamepad", for example, are defined as kHIDUsage_GD_X and
kHIDUsage_GD_Y in MacOSX/C; ABS_X and ABS_Y in Linux/C; or, abs_x and
abs_y in Pd/[hid].
In C, this is done using #defines which are mapped to integers. So
when you are programming in C, you don't need to remember those
integers, you use the #defines, which are easy to read symbols, like
kHIDUsage_GD_X, kHIDUsage_GD_Ry, kHIDUsage_GD_Slider, or
kHIDUsage_GD_Wheel (MacOSX); or ABS_X, ABS_RY, ABS_THROTTLE,
ABS_WHEEL(Linux). I think we can use symbols in Pd also, plus there is
the added benefit of being more efficient to compare (as you, Matju,
helpfully outlined). In [hid], symbols such as abs_x, abs_ry,
abs_throttle, abs_wheel are derived from the Linux names, which are in
turn derived from USB HID.
so I haven't tested a "Multi-Axis Controller" with [hid] yet, that
might change my perspective.That's another thing I wonder about. How many axes does it take before
something becomes "Multi-Axis" ?
"Multi-Axis Controller" is defined in USB HID, like like "Mouse",
"Joystick", "GamePad", "Keyboard", etc. etc. If you want to know
exactly how its defined, I suggest you RTFM.
As for the [gate 7] option, you could just [route abs_x abs_y abs_z]
to [gate 3] for example.I don't understand. I'm not talking about abs_x abs_y abs_z, I'm
talking about a row of seven distance sensors parallel to each other.
Should I name them abs_z1 abs_z2 abs_z3 abs_z4 abs_z5 abs_z6 abs_z7 ?
See above about how USB HID defines element IDs.
I've never heard of [shunt]
It's just the same as [demux] or [gate], really, but it's compatible
with jMax's [demux].If I have really a lot of sensors, I could instead use [for 0 64 1]
-> [sprintf in%d] -> [listfind], or I could use [atof] (that I
posted a few days ago).This is really not HID stuff. The vast majority of HIDs have 4 or
less axes and 8 or less buttons.Ok, so human interfaces that are made with axes are not human if they
have too many axes?
Ask the USB people, they defined it.
Sounds to me that you like you work in your own specific ways:
[listfind], [atof], [shunt] for example. I am gearing [hid] to
normal Pd use.Wow. It's not about liking to work in my own specific ways. It's about
finding ways to circumvent [hid]'s symbol restriction so that I don't
need to copypaste. If I don't have access to abnormal Pd use (that is,
GridFlow), then I just have to do [route abs_z1 abs_z2 abs_z3 abs_z4
abs_z5 abs_z6 abs_z7 abs_z8 abs_z9 abs_z10 abs_z11 abs_z12 abs_z13
abs_z14 abs_z15 abs_z16 abs_z17 abs_z18 abs_z19 abs_z20 abs_z21
abs_z22 abs_z23 abs_z24 abs_z25 abs_z26 abs_z27 abs_z28 abs_z29
abs_z30 abs_z31 abs_z32 abs_z33 abs_z34 abs_z35 abs_z36 abs_z37
abs_z38 abs_z39 abs_z40 abs_z41 abs_z42 abs_z43 abs_z44 abs_z45
abs_z46 abs_z47 abs_z48 abs_z49 abs_z50 abs_z51 abs_z52 abs_z53
abs_z54 abs_z55 abs_z56 abs_z57 abs_z58 abs_z59 abs_z60 abs_z61
abs_z62 abs_z63]. That's more like a normal human Pd patch.
I should explain what I meant more. Personally, I'd like to see Pd
programming stay within Pd, instead of being made up of objects written
in C. I think Pd has the potential to be a programming platform in its
own right, rather than just a bunch of objects written in C. I think
this problem at hand can be solved within Pd without too much grief.
But, of course, you are free to do things however you choose. You can
even hack you're own version of [hid] if you want.
This is an extreme situation, so it won't be the most attractive
solution, but if you chain [route]s in abstractions, it becomes quite
manageable. For example:
[route abs_x abs_y abs_z abs_rx abs_ry abs_rz]
|
[route abs_throttle
abs_rudder abs_wheel...]
Yes, this is not pretty, but you are trying to force the USB HID spec
to do something it wasn't designed to do, so its going to be ugly.
.hc
There is no way to peace, peace is the way.
-A.J. Muste
On Thu, 23 Jun 2005, Hans-Christoph Steiner wrote:
For example, the Linux input event system does not allow more than 64 absolute axes, and only half of those axes are even defined.
This is why I asked Christian Klippel to change the Multio so that it also works as a non-HID device. This way I just have to code my own [multio] object using libusb-for-Ruby (another part of GridFlow).
Originally Christian was instead recommending to apply a patch to the kernel source, but I think most users are too lazy to compile their own kernel -- at least I know I haven't been willing to do so since 2000 or so.
[hid] aims to support that spec, not every input possibility under the sun, but I think it can work for you without too much hassle.
All our plans about using sending axes values through USB involve the MultIO and only the MultIO.
It seems to me that you are saying that I should tailor [hid] to work for every single input possibility.
I am not forcing you :) but I think it's an easy feature to support. I mean, you really don't have to pick one model or the other: that's a false-dichotomy. It's not an either-or situation. I suggest that you implement it this way:
You could make every event message carry both the sensor-name and the sensor-number. Or maybe sending a "mode number" mode could switch to number mode and allow "mode name" to switch back to name (symbol) mode.
That would greatly impair the usability for almost everyone else who is going to use it.
It could default to "mode name" so that the default behaviour of [hid] is like the old behaviour of [hid].
What you are trying to do with your array of sensors is barely in the realm of USB HID. This is not defined by me, this was defined by the USB organization.
I'm sorry for wanting more.
USB HID is about mice, joysticks, tablets, gamepads, etc. There is no USB device type "64 range finders in a row". The USB HID spec is a perfect example of design by company getting their little piece custom piece in.
I'm sorry for my misconceptions.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
Am 25.06.2005 um 22:56 schrieb Mathieu Bouchard:
This is why I asked Christian Klippel to change the Multio so that it also works as a non-HID device. This way I just have to code my own [multio] object using libusb-for-Ruby (another part of GridFlow).
That means it would not be compatible with OS X or Windows anymore without special drivers, right?
Thomas
On Sat, 25 Jun 2005, Thomas Grill wrote:
Am 25.06.2005 um 22:56 schrieb Mathieu Bouchard:
This is why I asked Christian Klippel to change the Multio so that it also works as a non-HID device. This way I just have to code my own [multio] object using libusb-for-Ruby (another part of GridFlow).
That means it would not be compatible with OS X or Windows anymore without special drivers, right?
libusb is compatible with OSX. I have used libusb+GridFlow+Pd on OSX to do some testing and it worked.
and if you read my email correctly, I said:
"change the Multio so that it also works as a non-HID device."
you quoted that line yourself.
It means that for those who are stuck with Windows, they still can use the Multio in HID mode.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
| The Diagram is the Program tm| | ,-o-------------o--------------o-.
-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801---' `-o-- http://artengine.ca/matju -'
libusb is compatible with OSX. I have used libusb+GridFlow+Pd on OSX to do some testing and it worked.
and if you read my email correctly, I said:
"change the Multio so that it also works as a non-HID device."you quoted that line yourself.
Oh i'm so sorry, you are right. My fault. I deeply hope this won't happen again.
sincerely, Thomas
hi all,
(sorry, was off the net for two weeks, just got back online....)
[...snip...]
Is it sufficient that it respect the USB-HID protocol for it to qualify as Human Interface, or does it have to name axes?
so I haven't tested a "Multi-Axis Controller" with [hid] yet, that might change my perspective.
That's another thing I wonder about. How many axes does it take before something becomes "Multi-Axis" ?
[...snip...]
these names are hid-names as specified by the usb hid spec. you can find a list of the names in the kernel hid/event sources, for example. but of course you can find them also in the hid spec's.....
the device does _not_ define these names as strings, that comes automatically. in the descriptor, the usage-id (that is what gives name) is represented numerical. depending on the type hid device (the so-called usage-page, here the multi-axis-controller page) you have a different set of names for those numbers.
multi-axis is just a device that can specify that go beyond x/y/z abs/rel, and just some buttons/keys.....
i choosed the multi-axis controller page because it is at nearest to the stuff like mouse/keyboard events. i could make the usage-id's (each in/out channel has its own id) starting at a lower number. the side-effect would be that certain analogoue inputs would control your mouse then, and certain digital inputs the keys of your keyboard.
using a different usage page would result in _completely_ unrelated names like "batt low" (as in the ups usage page of the section power-devices, also set forth in the hid spec's), etc.....
also, because of a limit in the linux event system, you cant use all the available i/o (as in a maximum config like 88 adc inputs). first, there are not that many events defined in the spec, but allowed to be used, and second there are limits like "ABS_MAX" in the linux event system module which impose that restriction.... to really use it fully, one would have to change the sources of the event sytsem (easy, as example on my site), or use the second, non-hid configuration of the device.
im open to any suggestions about the right-now used usage tables and id's, to find something that fits better maybe...
so, now keeping up with the more mails & stuff,
chris
-
Christian Klippel -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
ix＠replic.net -
Mathieu Bouchard -
Thomas Grill -
vade