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 -'