> And yeah, MIDI is old, and has a few hard design limits, and one could make a case for looking at another standard like Open Sound Control.
Yeah, I was actually thinking of MIDI (and USB) when I wrote the above (I have a full size midi master keyboard next to my deskop). At a certain level, we have pretty much all we need, and if the limitations of MIDI were a problem for some input devices (and they arguably are), it'd still be quite easy to spec a system that allows just about any device imaginable. Again, USB HID spec comes really close.
The real problem is just the lack of good, widespread, cross-platform APIs that steer applications into doing the right thing. Now we have APIs that encourage the application to look for keyboard events, then mouse events, then joystick events, and what else (and they implementations may lack support for other devices even if the underlying OS-level API made support a no-brainer).
Instead, they should just look for events, any events that have an applicable type. (Whether implemented through callbacks or polling the state of interesting inputs is merely an implementation detail) Then the (optional) metadata can be used for establishing a default mapping. When the API is designed right, the user can always override any mapping with whatever he wants, or filter inputs to change the response of an analogue device, perhaps nonlinearizing it or coercing it to a binary input. And if the application provides its built-in input configurator, again using the well-designed API, the ability to bind anything to anything on anything just comes automatically. The application developer should never need to know that device 7 input 2 is actually wired to my belly button. :) And that the axes I use for aiming are actually sliders on my MIDI keyboard.
Yeah, I was actually thinking of MIDI (and USB) when I wrote the above (I have a full size midi master keyboard next to my deskop). At a certain level, we have pretty much all we need, and if the limitations of MIDI were a problem for some input devices (and they arguably are), it'd still be quite easy to spec a system that allows just about any device imaginable. Again, USB HID spec comes really close.
The real problem is just the lack of good, widespread, cross-platform APIs that steer applications into doing the right thing. Now we have APIs that encourage the application to look for keyboard events, then mouse events, then joystick events, and what else (and they implementations may lack support for other devices even if the underlying OS-level API made support a no-brainer).
Instead, they should just look for events, any events that have an applicable type. (Whether implemented through callbacks or polling the state of interesting inputs is merely an implementation detail) Then the (optional) metadata can be used for establishing a default mapping. When the API is designed right, the user can always override any mapping with whatever he wants, or filter inputs to change the response of an analogue device, perhaps nonlinearizing it or coercing it to a binary input. And if the application provides its built-in input configurator, again using the well-designed API, the ability to bind anything to anything on anything just comes automatically. The application developer should never need to know that device 7 input 2 is actually wired to my belly button. :) And that the axes I use for aiming are actually sliders on my MIDI keyboard.