[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….