Spencer; Now why would you ever want to open a device by name if it wasn't connected

to your system? :)

Easy! hi.open("Crackin DJ Console"); It's not connected to my system, in fact I don't think there even is on in the whole of the Netherlands, but I'd still really like to have one attached and open it.

Thanks for the bug report. Should be an easy fix.

Looks like it, yes. Some notes; It's not clear what we would do if we'd have multiple identical devices attached, that we'd still like to open by name for readability and because there might also be other devices of the same type. Let's say (purely hypothetically, of course) two identical toy turntables and a joystick. Could we overload this to .open(string name, int id) for such cases? I hadn't realised we had this until I went over VERSIONS just tonight and realised I had been implementing this exact functionality for the MIDI objects by incrementing id and repeatedly opening the device until the .name() matched the string I was looking for. Could we also get this for the MIDI abstractions? I know that at least Windows will swap the device order around when I boot without the external soundcard attached; it'll move it's internal GM synth to the top of the list (to not default to a unavailable device) but it doesn't move it back after I re-attach the card. Hence; I implemented basically this for the MIDI devices (so Windows can swap stuff around if it feels the need), I think .name(string) would make sense there too. Thanks, Kas.

'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.

Michael; Are you referring to some class in ChucK MIDI support, or an user

class in .ck? I just wrote something simple for the Korg nanoPAD last night

0 => int device; NanoPad nanoPad;

I'm basically doing exactly what you are doing, except for the Akai LPD8. Kas.

Michael. Cool, I think I like the control knobs on the LPD8 better than the

pseudo-touch pad on the nanoPAD. It only sends accurate values if you drag along either the X or Y origin.

The build quality of the Akai also feels better and the pads light up if you send them MIDI. I'm quite happy with it. No modulating by varying pressure though, it only detects velocity, even CC's need to be send percussively. And the editor is Win only and not that clear. Kas.