(I cc'ed the Pd list since I think this stuff is of general interest)
On Nov 26, 2004, at 1:51 AM, eyem wrote:
Hi Hans,
I am just playing with [hid] 0.13 .... on linux (2.4.18) with a Wacom
Saphire tablet.It works ..... but I'm not sure if there are bugs or if my useage is incorrect. Can you help me with the following:
- how can I reduce the sensitiveness of the pen (Christian Klippel's
jMAX [USB] object can do this so I assume it is possible). Is this possible?
- I dont seem to have access to the pressure of the Wacom pen (I
guess that's related to the 1st question)
I haven't played much with tablets so I don't know the details. But I
want to borrow a tablet and work out the details. But it would
definitely speed things up if I had my own, in terms of motivation and
ease of working. Too bad I am too broke to buy one... (hint hint ;)
- if I move the pen slowly into range of the tablet, the help patch
shows a '1' message on btn_0. .... if I remove the pen quickly, the '1'
message goes to '0' (correct behaviour).. but if I attempt the same with the back
of the pen, btn_1, when I remove it quickly the '0' (off) message is not
registered. (is it a hardware thing?).
I am not sure what btn_0 and btn_1 are in this case, since I haven't
tested the tablet yet. But this sounds like it could be a bug. I know
that under GNU/Linux if the poll time is set slow (like 20 or more),
that events like button pressed could be lost. I haven't had time to
test this in depth. What needs to happen is to have all events being
queued, then Pd checks the queue. I thought maybe that this queue was
built-in to the /dev/input/event? interface, but I am not sure. On
MacOS X HID Manager, the API provides queues.
- I get no relative coordinates. I suspect this is something I have
to switch in the Wacom driver, does that sound right? ... or is there a way to
switch that using the hid object?
What part of the tablet should give relative coordinates? The tablet
senses absolute position of the pen since its limited by the size of
the tablet. Relative coordinates seem only useful or necessary with a
device like a mouse, that has no fixed reference point (like the edges
of the tablet). For a device that outputs absolute data like a tablet,
I think that velocity is more useful than relative mode. This is what
relative axis data is anyway: amount traveled (usually pixels) per unit
of time (refresh rate of the device).
- CPU useage is very high at polls of 20 ... what is the recommended
poll useage? .... ok I know that is relative to the application, but what
owuld you use? 50?
Personally, I use 5ms since I want to have a good response time and CPU
usage is less important to me. Also, it doesn't make sense to use
a really fast poll rate if the device you are polling doesn't refresh
very fast. I generally poll twice as fast as the refresh rate of the
device to minimize latency. If you poll at the same rate as the device
refreshes, you could get up to double the latency (if [hid] polls right
before the event is reported). Ideally, a callback would be used when
events happen rather than polling and its added latency, but there
isn't really a mechanism to do this in Pd right now (AFAIK).
But this is one of my concerns with using names rather than numbers
since it takes a lot more CPU power to do pattern matching of symbols
that it does for floats. So I think the plan for the future is to make
[hid] the easy to use, cross-platform object for HIDs, and then also
make [linuxhid], [darwinhid], and [windowshid], which will provide
direct access to the native HID APIs on those platforms. These would
output numbers for event types and codes rather than symbols, so the
CPU usage would be lower. But they wouldn't be as nice to use, and
they will only work on one platform.
.hc
if you think it would be useful to take these questions to the list,
then please fel free to answer on the list, then we can take it from there.thanks for the object!
Etienne
¡El pueblo unido jamás será vencido!