Tuesday 12 April 2011

Some thoughts on conductive thread and a sneak peak at some coding

With a heavy heart I had to solder some wires into the gloves this morning. Not the finest hour when you are trying to make everything with thread, but a long string of errors led to this point, at first a few sensors stopped working or gave zero values, and the switches tended to randomly decide if they worked or not. I went through a long troubleshooting process with this, including checking the power hookups and arduino code. It was checking the arduino that really provided the answer as the software would no longer talk to the microprocessor and allow you to update it with the usb connected. Now normally even with everything hooked up to the xbee breakout board it updates fine (as long as the xbee isnt in the board) but this time I was getting an "arduino not in sync resp=0xf9" error when trying to upload. My first thought was that it was something to do with the xbee board, as this also gets involved when your uploading programs to the arduino due to the tx and rx wires being connected. So I disconnected them and the program uploaded fine. Somehow the conductive thread was stopping me updating the firmware, which could of course also account for some of the funky values I was getting into my maxuino patch.

After a lot of thought I've decided that mission critical wires need to be actual wires rather than thread, as things like the tx and rx getting shorted out or returning weird values isnt an option when your playing live, it all has to be bomb proof. Now there are still a few sensors acting funny and switches being intermittent in their response and this is clearly due to the thread. So firstly thats going to get replaced and ideally sewn between layers of neoprene instead of being latexed to see if that makes it more reliable and then dependant on the outcome I might need to break out the soldering iron again, I really dont want to, but the most important thing is that it works not that something in particular is used if its not suitable for the task.

Original Maxuino
Heres a brief snapshot of the code for one of the hands, im essentially running two copies of maxuino that have been heavily edited to do what I want... Firstly heres the original maxuino patch, as you can see apart from the subpatchers that deal with the OSC commands and do the javascript theres not a huge amount to it, midi comes out of the end and there you go job done. Now lets have a look at the left hand code for the gloves.....




My Maxuino Left Hand Patch
 This is the patch im running right now, basically everything bar the core maxuino patcher has been edited in some way to suit my purposes, theres an additional lighting system, routing options so you can send the midi via the internal max network of s and r objects to other channels (this is really important so you can control more than one instrument with your inputs and requires a little receive object to be placed on the channel your looking to send to), a calibration system, options to turn on and off sensors (as you dont want things happening every time you bend your fingers to hit a note or drum. Or maybe you do, you can do that too) and also inputs from the other gloves to control certain parameters, ie switches to change octave, channel the midi is routed to etc...... Quite a bit of data is passed back and forth to make things work, luckily max is fast at doing this and it doesnt cause any kind of unusable latency. However there is a little quirk that you have to work around. This patch has to be frozen to work properly, and you cant use an r object in a frozen patch. It is possible to add one but it causes a constant climb of the cpu usage second after second, so you end up with ableton telling you that you have 300% cpu usage or something ridiculous. However if you pop the R object in an external patch and bpatcher, or whatever, it into your frozen patch everything is fine. So theres a little workaround if you need it.

More on the coding soon.... for now back to conductive thread experiements

2 comments:

Onyx-Ashanti projects said...

i would imagine that the thread probably shifts a bit, which would give weird readings. maybe solder the thread to an anchor of some sort that would give a 100% connection. just a thought.

the quest continues!

Unknown said...

the lilypads have a wide contact area to try to negate that, and holes that are big enough to put the thread through a few times, so you can get a pretty secure connection. I think the problem is mainly cramming so many bits of thread on and then if you latex them some of the latex seeps into the thread (imagine the thread is multicore wire without any kind of insulation) and you can see the problem separating the threads would cause. I think its a case of having to build up 'layers' of wires sandwiched between neoprene to get it all to work, i think thats the next build!