[chuck-users] Hid open by string [bug]

[Kassen]

'ey Spencer!

Yeah, that makes sense.  I guess it wouldn't be bad to have
> .countNamed(string name) or something liked that to tell you the number of
> devices with "name", so you know the range of id in .open(string name, int
> id).  Right now open(string name) just opens the "first" one it finds, which
> I would expect to be pretty arbitrary and inconsistent.
>
>

That would be better indeed. I was imagining it just reporting a failure if
we went out of range, like we currently do with opening devices beyond the
number -of that type- found to be attached. Interestingly I found that here
the OS's I use are quite consistent. I have one Playstation to USB converter
that registers as two devices of the same type with the same name but the
order is always the same. Same thing with the devices abstracted as a HID
keyboard by Linux (which on my computers includes some quite unexpected
things). I think that beyond that identically named devices go in order of
USB ports, and that that too is consistent, I'm not yet sure how USB hubs
might affect this. I've never seen a simple reboot on it's own affect device
order (now that would be bad).

Wrapping 'round the id#, like for example the presets on Shakers do, is no
option here as there would be no other way to keep them apart and detect
issues like accidentally unplugged devices, with all having the same name.
Somehow the USB specs seem unprepared for this situation, while it seems
quite obvious; if we are going to play a 4 player game competitively it
would make sense to all use identical controllers. The more I think about
this the better cour suggestion seems as a plan.


>
> Yup, this is in the works for MIDI also.
>

Great. That would be very useful for abstracting MIDI devices we own to a
single class once and have them opened by that class at instantiation. I
hate coding for MIDI as it's all magic numbers, all the time, so I prefer to
only have to do it once per device.

As an aside; I updated the documentation for Hid in the new manual and
changed the name from the now deprecated "HidIn". What I can't find is
documentation on Hid.read(int, int, Hidmsg), beyond a reference to it's
existence. Could you sumarise this? I could also look into the source or try
to see the pattern in looking at a lot of messages but if you have the info
that would be a lot easier.

Another thing I found is that I can attempt to open a sudden motion sensor
under Linux, while this feature seems Mac only right now (I don't think this
laptop even has one), the call gets through yet the related poll-rate
setting won't run. Is this intentional? Maybe the call to the SMS should be
Mac-only until the powers that be can settle on a standard? As far as I can
see this is extremely minor as a issue and couldn't possibly cause any
problems but it might highlight a underlying consistency matter in
OS-dependant compiler flags. I'm really not sure here, lacking a non-Mac
laptop with a SMS to base testing on.


Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091219/7989cfd4/attachment-0001.html>