[sharing/testing] multiple sensors to Max; from one n00b to another
For several weeks I was faced with the challenge of parsing data from multiple sensors in MaxMSP. 15 FSRs need ‘hardwired’ to a predetermined pitch set. However, sending this data over the serial port introduces a variable: the timing of serial initialization prevents reliable ordering of the multiple data stream, i.e. sensor1 – sensor15 may not always arrive in that order, depending on when the serial object is initialized. After much head-scratching, forum-pounding and extensive research, the solution lies in ‘tagging’ the bytes with a header value. Before each serial byte is sent, pair it with an ascii value ("1" = 49, "2" = 50 etc). Then in Max, the [zl group 2] makes the pair (header ascii and readVal), and [route 49 50 51.....] parses the tags. It seems to work even if the readVal coincides with an ascii value. This is a proof of concept patch, demonstrating the intended functionality.
Have you tried Maxuino?
Easy enough to route from Arduino pins then
or am I missing something here?
I totally understand your concern/comment – "why re-invent the wheel?" as my PhD supervisors are always saying. But. I have tried a number of these ‘prefab’ solutions, including Maxuino, SARCduino and others. I am building a customized interface for users with physical disabilities and consequently need to maintain optimum ‘tweakability’; because my programming skills are a little limited I can’t hack these prefabs, so I need to build my code from scratch, meanwhile developing my own nascent programming skills.
Hmm, I think I’m with your supervisors.
I have been working with the disabled community for the last ten years or so, have used several different micro-controllers & lots of different sensors often FSRs.
Its always good to hone your skills, but these days its also too easy to take one’s eye off the target with diversions.
I don’t seem to follow what ‘tweakability’ you are gaining by adding tasks on the Arduino.
Does your code yield noticeably less latency in sensor operation?
-Sorry, devils advocate mode ;-)
do you have any links to your work?
I also favour FSRs, for their tactility, but I have built my own, and I have also hacked a resistive touchscreen. I don’t regard hacking/programming as a diversion, rather a key component of custom interface design. I and my participants demand control over all elements of the environment.
Thanks for posing these reservations though, as I will no doubt encounter the same and more in my end of PhD viva voce.
You might enjoy this thread of mine….
my own website is err ‘under revision’…..
Poor self-publicity on my part,as for me, that is a diversion.
Keep on keepin’ on Brendan!
"You might enjoy this thread of mine…."
which I forgot to link to