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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
==============================================================================
= check out GDAM HID implementation
- GDAM has a HID Manager implementation and probably a Linux one too
==============================================================================
= profile [hid] object and usage
- find out how much more CPU the names (btn_?, abs, rel, etc) use over using
just floats.
==============================================================================
= define generic event timestamp struct (probably Pd-ized input_event )
The question is whether the timeval is needed at all. Linux and Darwin
support it. Currently, I can only think of UPS PWR events actually using
timevals.
The timestamps should be in seconds since the first [hid] object was
instantiated since Pd limits float resolution to 6 digits. If there were two
floats, one for seconds, and the other for microseconds, then the [hid]
timestamp could represent up to 11.5 days (999999 seconds).
==============================================================================
= device selection
by # (1,2,...), generic name (mouse1, joystick2, tablet3...), or device name
("Trackpad", "Microsoft 5-button Mouse with IntelliEye(TM)", etc.)
==============================================================================
= figure out how to store device ID in obj struct
(in SC_HID.c its locID and cookie)
- it should probably just store the Pd arguments
- this will have to be dealt with when the "mouse0", "joystick2" arguments are
implemented
==============================================================================
= pollfn for mouse-like devices
- determine whether using a pollfn is actually better than using a t_clock
- any device that acts like a system mouse can be used with a pollfn, since
the mouse data will go thru Pd's network port, triggering the pollfn.
- this is probably unnecessary since the t_clock seems to run well at 1ms delay
- at standard block size (64 samples), one block = ~1.5ms
==============================================================================
= function return values
- most functions probably do not need return values
- return (1) seems to be the default on many functions
==============================================================================
= control input messages
- are [poll(, [start(, and [stop( needed? is 0/1/del# enough?
==============================================================================
= consistent console output
void hid_post(const char *format, const char *);
==============================================================================
= event name changes
- make key/button Type btn rather than key (undecided on this one)
==============================================================================
= make [linuxhid] [darwinhid] and [windowshid]
- so much info is lost in the translation to a common event scheme that it
would be quite handy to have platform-specific objects. This would give
access to the entire range of devices supported by HID Manager, Linux input
events, etc.
- these objects should follow the same conventions as [hid]
==============================================================================
= device 0 gets events for all available devices
- it might be useful to have device #0 open all available devices and output
the events.
==============================================================================
= figure out whole degree issue
- BUG: zexy's 3D conversion objects just pass through Z rather than converting
it to elevation in rad/deg.
- make [hid_polar] output 0 to 1 for angle rather than -pi to pi
- [hid2rad], [hid2deg], [rad2hid], [deg2hid]
- should degree conversion also change rotation direction and 0 point? The
degrees on a compass rotate the opposite direction of radians. The 0 point
of a compass is due north, with radians, its right/due east.
- [hid_polar] should take an argument (in degrees?) which specifies where the
0 is on the circle
==============================================================================
= mapping object ideas
[hid2midi] [midi2hid]
midi value + bend <-> hid
- use MIDI pitch and bend data for values in between MIDI notes?
object for Fletcher-Munson Equal-loudness contours
median average object
non-linear one-to-many mapping object (one curve spans the whole range of the
movement, the other curve kicks in at a specifable point. Arguments could be
start-point and start-value.
[infinitepot] for use with a [knob] or any single axis that could be infinite.
[hid_debounce]
[hid_vector] - angle and distance for mouse/relative data
peak finder object
"kalman filters"
Curves!!
http://www.2dcurves.com
/++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
\++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++/
______________________________________________________________________________
- BUG: getting events from the queue doesn't output a 0 value event when the
motion stops, so when the mouse stops, the sound keeps playing.
This is probably only a problem on relative axes.
This will probably have to be implemented on a platform-specific level:
- On Darwin/MacOSX, I think that the HIDGetEvent() loop will have to be
followed by one call to HIDGetElementValue()
______________________________________________________________________________
- BUG: hatswitches on MacOS X output an event without a change in value
Because of the currnently implementation of the conversion of the MacOS X
style event to the Linux style event, an event with a value of zero is output
on the unchanged axis when the hatswitch is moved in along the X or Y axis (as
opposed to diagonally).
______________________________________________________________________________
- BUG: on MacOS X, mouse axis data is limited by the screen dimensions
- the axes data stops outputting when the mouse pointer reaches the edge of
the screen. Hopefully the HID Manager API will allow raw mouse data
access. It must since its used with games.
______________________________________________________________________________
- BUG: on MacOS X, two keyboard key codes are reported as hatswitches
abs abs_hat0x Button Input, Keyboard Usage 0x39
abs abs_hat0y Button Input, Keyboard Usage 0x39
I am pretty sure this is just a hid_print_element_list() display problem.
______________________________________________________________________________
- BUG: multiple instances pointing to the same device don't have seperate close/free
- closing the device on one instance closing that same device on all other
instances of [hid]
- deleting that instance also closes the device for all other instances
pointing to that same device
|
