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