[PD] HID parsing for Pd

[Christian Klippel]

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