1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
#N canvas 0 25 1367 915 10;
#X obj 49 116 route 0 1;
#X obj 49 10 loadbang;
#X obj 49 45 input_noticer joystick "SideWinder Dual Strike";
#X obj 110 10 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X text 549 12 INSTANTIATION ARGUMENTS:;
#X text 549 31 1) device type: for instance \, as I have entered here:
joystick;
#X text 658 182 This external takes the "joystick" that I have entered
\, and creates "input.joystick" from it \, and then asks HAL to look
for all devices that have that capability.;
#X text 659 275 In linux \, this references the HAL info.product field
for the device. The input_noticer will iterate through all devices
that HAL returns with the given Capabilities field (see above) \, and
look for the user-supplied substring. The corresponding linux.device_file
field is returned \, which will be something like "/dev/input/event6".
This can be used to connect to objects like [hid].;
#X text 127 10 <- BANG to scan for devices \, outputs any that are
found;
#X text 13 430 Output from input_noticer is a list \, like 0 \, /dev/input/event5
1 \, /dev/input/event6;
#X text 59 552 5 means /dev/input/event5;
#X text 661 60 In linux \, this references the HAL (Hardware Abstraction
Layer) Capabilities field for the device. You can have a look at what
your favorite device has by using the HAL Device Manager \, and look
at the "Device" tab of the most specific entry for your input device.
In my case \, the device tree for my joystick looks like: "SideWinder
Dual Strike" -> "USB Hid Interface" -> "Microsoft SideWinder Dual Strike
USB Version 1.0". Capabilities listed are: input \, input.joystick
;
#X text 549 236 2) product substring: for instance \, as I have entered
here: "SideWinder Dual Strike";
#X text 11 509 To feed this to [hid] \, you'll need to strip the number
from the end \, since [hid] currently wants just the number \, and
interprets the number as follows:;
#X obj 49 180 parseeventnodenum;
#X floatatom 49 202 5 0 0 0 - - -;
#X obj 79 294 hid 0;
#X msg 79 250 open \$1;
#X obj 49 221 t b f;
#X msg 34 249 start;
#X text 173 181 <- converts '/dev/input/eventX' to 'X';
#X text 11 476 Use [route] to separate the messages \, and you'll be
left with the second list element \, like /dev/input/event5;
#X text 120 295 <- gets told which /dev/input/eventX to use;
#X text 258 309 then is opened \, started;
#X text 9 410 USING input_noticer:;
#X text 57 74 <- outputs are tuples like 0 \, /dev/input/event5;
#X text 246 89 1 \, /dev/input/event6;
#X text 246 104 etc...;
#X text 56 148 <- add more below here for multiple input devices;
#N canvas 282 199 759 562 creating_input_abstractions 0;
#X text 31 23 The philosophy behind input_noticer is really "plug and
play". It's silly to have to manually figure out which device file
a piece of hardware has mapped to \, then change your PD patch to match..
Or to have to make sure to plug your devices in in the same order every
time \, to make sure that the device files get created in a deterministic
way \, etc..;
#X text 30 122 The point of input_noticer is to make all of this "just
work" \, so that you can get to the more interesting parts of interaction/instrument/sound/performance
design.;
#X text 30 167 -David Merrill <dmerrill@media.mit.edu>;
#X restore 48 605 pd creating_input_abstractions;
#X obj 79 321 route abs;
#X floatatom 79 365 5 0 0 0 - - -;
#X obj 79 343 route abs_x abs_y;
#X floatatom 136 367 5 0 0 0 - - -;
#X connect 0 0 14 0;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 3 0 2 0;
#X connect 14 0 15 0;
#X connect 15 0 18 0;
#X connect 16 0 30 0;
#X connect 17 0 16 0;
#X connect 18 0 19 0;
#X connect 18 1 17 0;
#X connect 19 0 16 0;
#X connect 30 0 32 0;
#X connect 32 0 31 0;
#X connect 32 1 33 0;
|
