16 mux always causing trouble
I hooked up my new 16 FSRs to the breadboard, with the original multiplexer, and new HUZZAH feather. The results from that... well.. proved that I probably need more reliable breadboards. Still, I did notice that when I pressed on the FSRs for pins 15/16, they still bled into each other. But, pin 15 was not resting at 0, whereas pin 16 was resting at zero. I also tested each FSR individually and they all work well. I believe it's just the connections in either the wires or the breadboard itself that is causing it to go a little crazy. Now I'm wondering if I have another breadboard somewhere that I lost during one of my many moves. I don't remember having this problem the first time around with testing on a breadboard.
In the end, I'm still not sure if it is the multiplexer itself that is allowing pins 15/16 to bleed, or if it is my circuitboard and breadboard that both are messing it up. Maybe the only sure thing to do is finally learn how to design and order a custom PCB for my circuitboard.
I got more fabric paints to try, and I was right; it does work better with lighter shades. All of the new paints work well. In the picture I like the top blue and the bottom green the best out of the new ones. That green is a different brand from the rest of the colours and it isn't as shiny. I think overall I like that non-shiny look better, but the paint bottle itself has a bit of a difficult applicator than the other bottles. I would have to use a paint brush to use it accurately. The lighter orange still looks fairly close to red. I also noticed that these fabric paints soak right in to the fabric. So I bought a bag that is made for these kinds of crafts and plan to take it apart and sew it into gloves for performance.
I also finished soldering headers to all of the 16 channel multiplexers that I had. I mix-matched different colours so I wouldn't confuse them.
6. Green/Red: 4/5 bleeds, 1/5 bleeds, 9/12 bleeds, and 10/15/16 bleeds.
7: Blue/Yellow: 1/15/16 bleeds, 13/15/16 bleeds
8. White/Red: Most pins read values around 41-43 (pins: 2, 4, 6, 7, 8, 10, 11, 12, 13, 14). Pin 3 sits at around 901-904. Pin 5 sits at 1024 and is unresponsive (all the rest do work even if they sit at strange values) . 15/16 bleed.
9. Red/Blue: 13/15/16 bleed. It was then that I noticed that when 13 is triggered, 15/16 or always lower than 13. So it is easy enough to program to ignore that and only trigger 15/16 when their values are much higher.
10. Blue/Green: 2/15/16 bleed (pin 2 is like how pin 13 behaved last time). 13/15/16 bleed.
11. White/Yellow: 13/15/16
Pins 15/16 consistently are equal with all of my chips, no matter what else is happening. It makes me think perhaps there is something that I missed that is causing that. I will test with one of the best boards and hook it all up with other FSRs and my other HUZZAH feather to test. If it has identical behaviour with the breadboard as the with the main circuitboard, then I know it is something that this chip does. So in reality it might actually be more of a 15 channel multiplexer than a 16 channel one. False advertising!
nEwS NeWs NEWS!!!!!
I've been selected as a finalist for the Guthman Instrument Competition 2022!
I've been assembling parts for a new version of the GLOBE. I'm still a long ways off. But I thought I would test out the FSRs and the 16 channel multiplexers. I haven't gotten around to testing every FSR, but the one that I did test works well.
I felt unsure if the issues I was seeing with the multiplexer was due to a bad breadboard or if it was the multiplexer. So I plugged it in to the GLOBE since I made the parts modular. It turns out you never know how good these boards will be. Also, I am pretty certain that the issues with a few bleeding pins in the original have more to do with the board than my connections. I have multi-coloured pins, so I am using different colours on each multiplexer in order to keep track. I have only tested 5 so far before having to call it a day.
So the turquoise and the lavender samples work very well. Blue I got to work a couple times, but it is very difficult. I had to keep trying and moving the blue sample around until it would change the LEDs. The green just was not working at all. I think maybe I'll go over the blue with another layer of paint, and make the green larger, and try these colours one more time. Or perhaps there is something about the way these particular paint colours reflect light that is not so friendly with the colour sensor.
If my memory of my childhood is correct, I think I had fabric paints that dried a lot faster and were a lot thicker than these ones before. These paints seem to soak through the fabric a lot more and take 4 hours to dry. I may visit Michaels soon and see if they have any other brands to try.
Update: After going over the green and the blue one more time, the blue is not any better. I was able to get the LEDs to register the green once. This is not good enough results for a performance situation. These two shades are darker than the other paints, so maybe it has to do with that. The orange also works, but I find it looks rather similar to red with the LEDs. I'll look to see if there are lighter blue and green paints that I could try.
Another note, I think I may have written about the wired connection issue already (can't remember). Basically, the ESP8266 refuses to spit out data through serial unless if the computer is connected to the wireless network first. Then after it starts printing the data through serial you can disconnect the wireless network and it is fine. This didn't start happening until we added the update to send brightness data from Max to the GLOBE. It hasn't been a problem so far since I'm not doing public performances where that backup method is needed (yet). While I was testing for the colours, I noticed that the GLOBE refuses to turn on its LEDs or change colours unless if it first connects to the computer wirelessly - which I think is related. It's like the ESP will not do anything until after a handshake is made, which is hopefully something I wish to fix (though it's lower on the priority list).
I figured out a much much MUCH better way to detect colours with the colour sensor. It turns the RGB data into HSL, and then the H is mapped to MIDI. There are far fewer chance of accidental false readings this way. An updated bpatcher for colour detection is posted to my GitHub: https://github.com/CLKo1/colourdetect-maxmsp
I have an idea of having the different colours on gloves. The thing is the colour sensor does not work with fabric. I had the idea to test 3D fabric paint with it. I remember from my childhood that this kind of paint has a flexible plastic-like texture once it drys. So I went out and got a set of 3D fabric paint from Walmart to test.
The Red works very well! The rest I had to go over them and made the samples larger in size. Then the Yellow worked well. The Blue and the Green definitely showed well inside of Max. But the LEDs did not change colours. So I am going over the blue sample again to make it wider. I also made a lavender/purple sample and a turquoise sample. We will see once they dry if they're okay. If I can get the blue working then I will try green again.
You may have noticed in some of my videos of the GLBE that the last section of LEDs sometimes does not light up. I'm pretty sure that was caused by the connectors I used coming loose. I noticed it when I was first making the GLOBE. I thought I had fixed it, but after it was all assembled I realized that it still wasn't 100% because sometimes that last strip of lights turns on and sometimes it doesn't. So I had purchased some 3 pin JST connectors and replaced those couple of troublesome connections. It was very tricky cause I didn't want to accidentally melt the plastic hamster ball while soldering!
I *think* it might be fixed now. But only way to know for sure it to play with the GLOBE and do lots of spinning/rolling with it.
I was also thinking about the IR sensor again and how to improve it. I have a level shifter and I knew there was a reason why I wasn't using it before, just couldn't remember what. I then realized that the level shifter still needs a 5V source, which the GLOBE does not have. I know that the Wemos D1 has a 5V pin on it, so maybe I'll try it when I start making the next GLOBE. I have a wemos, but I noticed that it gets very very hot, so I do not trust it. If I do determine that it is better to use that board so that way there is both a 5V and 3V pin I think I would look into getting another one just to see if another would still get too hot. And make sure I order it from a reliable source.
Guthman Competition 2022
I submitted the GLOBE to the Guthman Musical Instrument Competition and I made it to the semifinals! Now I feel motivated to fix a few things in the current design and 3D print a new GLOBE!
Kevin Mitchell, my life partner, has been helping me update the Arduino sketch. He made it so the LED strips accept messages from Max MSP to control the brightness. This posed a new challenge because in order to send brightness messages, we have to write down the ESP8266's IP address in the Max patch. We could not assign a static IP to the board. Therefore, when the board first turns on, it constantly prints its IP address and that gets read into Max. Then Max can send the ESP a 0 message and that makes it stop printing the IP address. The updated code has been posted on my Github: https://github.com/CLKo1/GLOBE_esp8266/tree/main/Thesis_Oct2_2021_nopassgithub.com/CLKo1/GLOBE_esp8266/tree/main/Thesis_Oct2_2021_nopass
Here is the video for my new piece, Triuir. The brightness of the LEDs and the brightness of the visuals are audio reactive.
New Spinning Stand!
I bought a whole new hamster ball just so I could get a stand that is made from metal instead of plastic. Hopefully it's more durable. I planned to bolt it down to a piece of wood to give it weight, so hopefully it is stable while the ball is spinning.
I told my dad of my plans, and of course he wanted to help and go full out to make it as amazing as possible (maybe a little overboard). My plans were simple: cut the wood, add a coat of black paint, and maybe 3D print some brackets to bolt it down. He convinced me to sand the wood, and prime the wood with a coat of white paint before painting it black. He also cut the perfect brackets from metal. We didn't have the right length of screws so instead of buying more he cut the longer screws that he had with fancy machinery. Thanks dad!
Max Controlling LEDs
This weekend I divided and conquered with my genius significant other, Kevin Mitchell, who just so happens to be a software engineer. I worked on my Max patch for the piece while he worked on tweaking the arduino code for the ESP8266 so that Max could send messages to it to control the brightness of the LEDs, but the colour sensor still controls the colour. At first he was having troubles with memory on the ESP, so when I sent a message with ramping values from 0-255 within 5000 ms the ESP freaked out mid way and reset itself. But he figured it out how the flushing worked and now it's working without explosions. In the upcoming piece I plan to make the LEDs audio reactive by having them turn off/on to the beat of the music.
Here are videos to demonstrate. The first is of it not quite working. You can tell when the LEDs suddenly flash and then turn off. The second video is of it working well and Kevin was clicking the button to rapidly turn the LEDs off/on quickly.
For my piece I've been working on getting binaural audio setup. And I tested the different sections with the GLOBE. I figured out that if lets say you have a playlist object that is playing, and while it is playing you change its start/end points that it loops, it will not jump to the new points, even if what it's playing is outside of its start/end points. For example, sending a message that says: [selectionms 0 86450.139046]. So for my looping sections, instead of having just one file to loop different parts of, I have to go back to Logic, cut the sections, re-import each section into Max, and fade in/out the parts when I want to transition.
I am also working on building a new spinning stand. Well the actually metal piece of it that the GLOBE attaches to was bought as part of a set for another hamsterball brand. But with my dad, we cut a piece of wood, sanded, primed, and painted it. Now we just need to bolt the wire stand piece down to the wood. This will hopefully give it more weight and make it so I don't have to hold onto the stand while playing like I did for the Etude.
Here is just the plain acoustic mix of what I plan to use as the base material for my piece:
If you are looking for a summary for my Masters thesis, it is here.