definiltely.
I've tried to create a girder scipt with this knowledge, but strangely it's only returning 6 bytes. I took off all the splitting code and did a simple string.length on the incoming data directly, it's 6 bytes for sure. Which means it's impossible to distinguish between interleaved lines. If the Poximis guys can sort that out, then I'm sure we can get a girder script to work also.
I have some ideas on how we can use this device:
I think we should ignore a small range at the begning of every axis otherwise there will be noise and overlap betwen functions.
In the configuration of the software, any axis can have different modes of operation.
MODE 1:
after a certain threshold, a thread starts a "pulsing" event. This would be slow with low values (little pressure), and as the pressure is increased, the pulse would get quicker. This will give a use for the analogue proerties of the device, and makes it possible to control the speed of for forwarding songs, cycling through playlists, volume change etc. The pulse/range mapping can easily be defined using a couple of arrays that can be defined in the config.
MODE 2:
just "presses" a single event per axis direction. pressure is not taken itno account. This is useful for switchign between different screens for example (GPS/Media/etc.)
I can think of antoher mode but I'm not sure what for!:
MODE 3:
segement the range to "press" a single event (not pulsing) at different threshholds.
I've also found that combining axis (like pan and tilt) you can create more quick-functions. Like holding the hat and tilting left but panning right. These quick presses are easy to model and diffrentiate.
I guess the best starting pont is getting this to work with RoadRunner, sending it simple messages, and then we can incorporate all these modes based on usage etc.
If anyone has any ideas, please post away.
Thanks for all the help cherry, coudln't have done anythign at all without your magic app!