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.