So I had a meeting with Tom Igoe (ITP/NYU professor and co-author of
Physical Computing) yesterday to discuss how to make generic Pd support
for sensorboxes. We agreed that the best approach would be to propose
a standard protocol for sensorboxes to support, regardless if they are
USB, serial, parallel, etc. (MIDI would probably have to be distinct).
We also agreed that HID makes a lot of sense as the standard protocol.
(OSC might be a better choice too. Maybe. But then you loose the
possibility of emulating mice, joysticks, etc. and having them "just
work")
(It was funny, during the meeting, we'd discuss various ideas, and come
to a conclusion. More than once, I said, "oh wait, the MultIO already
does this...".)
So in order to make this work, on the Pd side of things, there would
need to be an object that can interpret raw HID data and output in the
same format as [hid]. This object would not need to have the same
limitations that the USB HID implementations have, it could have
different MAX values that the USB Usage Pages or the Linux input.h
types. Anyone know of some USB HID parsing code to start with?
(On a related OT question, how hard would it be to port MultIO/PIC code
to Arduino/ATMEL?)
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin
hi again,
busy writing in this thread today ;)
Am Dienstag 24 Januar 2006 19:30 schrieb Hans-Christoph Steiner:
So I had a meeting with Tom Igoe (ITP/NYU professor and co-author of Physical Computing) yesterday to discuss how to make generic Pd support for sensorboxes. We agreed that the best approach would be to propose a standard protocol for sensorboxes to support, regardless if they are USB, serial, parallel, etc. (MIDI would probably have to be distinct). We also agreed that HID makes a lot of sense as the standard protocol. (OSC might be a better choice too. Maybe. But then you loose the possibility of emulating mice, joysticks, etc. and having them "just work")
(It was funny, during the meeting, we'd discuss various ideas, and come to a conclusion. More than once, I said, "oh wait, the MultIO already does this...".)
yes, i agree that using hid is a nice and good thing. things like osc, serial, etc... can be options to that ....
So in order to make this work, on the Pd side of things, there would need to be an object that can interpret raw HID data and output in the same format as [hid]. This object would not need to have the same limitations that the USB HID implementations have, it could have different MAX values that the USB Usage Pages or the Linux input.h types. Anyone know of some USB HID parsing code to start with?
that sounds like a good idea! well, i would take linux's module sources as a starting point. all the stuff is pretty much already done. maybe its even possible to take the related stuff from hid & event and thus more or less port the kernel modules to a pd object....
90% of the parsing is to interpret the device, to find out what values with what sizes are in the final report, according to the report descriptor.
(On a related OT question, how hard would it be to port MultIO/PIC code to Arduino/ATMEL?)
what code do you mean? everything, excluding the usb related stuff, should be straightforward to port. after all, i use c, so it should be no problem.
the new firmware will be much cleaner in that respect, the 16c765 firmware is quite clumsy ....
the usb part is hard, since it is pretty much fixed to the pic's on-chip usb hardware and registers. i would say, no way to easily port that....
.hc
greets,
chris
-
Christian Klippel -
Hans-Christoph Steiner