At first I thought it would be a better idea that when one battery dies, to unplug the battery wires from the HUZZAH and plug them into the other battery. But since it is more difficult than anticipated I added wires so that the HUZZAH will be plugged into both batteries at the same time. I just need to be extra careful to not turn both on at the same time. I also extended the battery wires so that they are easier to unplug/plug in. I also extended the wires on my Adafruit lipo charger. Hopefully in the future all of these modifications make it easier to charge the batteries.
Still chugging away at the second piece. I've chosen a bedtrack for each of the colours, red, green, blue, and yellow. I don't think I'll do purple or orange. I've also decided on what audio processes to use for the green, red, and blue. Now I just need to figure things out for the yellow. I chose Bees for the yellow bedtrack and it's proving tricky to figure out what I can do with it that sounds good.
0 Comments
I've been trying to come up with pieces for the GLOBE. My advisor said that I should focus on two contrasting ones and that they don't need to be too complicated; they just need to be able to demonstraight concepts very clearly.
A week or so ago I put together a patch to show off what it can do and roll the ball around on the floor for fun. I did it very quickly and I'm not much of a fan of the patch. So I'm starting over. I turned the colour detection part of the patch into a bpatcher because I know I would use it a lot and it's possible to use it for anything that outputs RGB data. I initially thought of doing one piece per playing technique that I came up with, for a total of four pieces. But that's too much. So I'm going to do one piece with the ball being constrained to its original hamster ball stand. This one will only use the accelerometer and the FSRs, it is mostly 1-to-1 mapping with little automation, and it will only use synths and possible MIDI. The other piece will have playing the ball on its 3D printed stand, picking it up, and rolling it on the ground. The sounds will be from recordings and possibly physical modelling. So far I've worked really hard on the accelerometer for the hamster ball stand piece. I mapped it to a droning synth that's made up of adding many together that are slightly detuned. They are sine, sawtooth, and rectangle waves. The position of the ball when it's spinning controls the cutoff of the filter, and the amplitude of each of the individual synths. The speed of which it spins controls the height of the Q on the filter. Other parameters are automated. Edit: I mapped half of the FSRs to a polyphonic Karplus Strong. And I can play chords with it! It sounds so soothing. The other half of the FSRs changes the pitch of the drone. The accelerometer also changes the filter on the Karplus strong. I thought it would be best to pull the blue LED on the ESP8266 low and have the red LED blink when the board is trying to find the network and solid once it finds it. Well I relized that the red LED is controlled by pin 0 and the blue LED is on pin 2. I am already using those pins for other things. If I had realized this sooner, I should have re-arranged the pins. Oh well. Ya live and learn. Just another thing to add to my speculative improvements.
So this whole time I've been programming the HUZZAH feather with my old windows laptop because not a single ESP8266 board will compile the blink example on my Mac. If I go back to old blog posts, I wrote about the problem in more detail in the past. It requires deep computer surgery and I'm not quite ready to do that on my Mac just yet.
Since I know that I have the code to print the sensor data through UDP and Serial simultaneously, I wanted to use that to add the wireless method to my Arduino to Max GLOBE bpatcher. I would use the matching serial and UDP readings to know which outlet to hookup to for each sensor. I thought it would be easier to do this all on my Windows in case if I needed to re-program the ESP8266. However, I was then having lots of troubles getting Max to print the data through Serial. I was confused because it was printing finr through the serial monitor while also printing through UDP. I finally figured out for whatever reason, my Windows has become unfriendly when it comes to allowing Max to print through Serial. It says that it's connected to port E and sometimes it will print, other times it won't. I have to delete the "e" in the argument of the Serial object and add it in again to get it going (sometimes). I tried plugging into my Mac again, and it was fine. So now I have the problem that I can only program the Arduino code on my Windows, and I can only use Arduino to Max (wired) on my Mac. Once I have everything finalized, this won't be an issue. But for troubleshooting purposes, this is kind of annoying. In the end I added the capabilities to toggle between serial and udp in the bpatcher. I added a little accelerometer mapping. And I started on my dissertation.
I spent a really long time figuring out how to format page numbers, the table of contents, and figures for my dissertation today. There really should just be a template for all grad students...
I was able to figure out how to make the TCS34725 wireless. Now I just need to understand how to also add the LEDs, then combine it with everything else! Edit: I DID IT!!!!! I DID IT! I DID IT!!!!!! And the best part is it also simultaneously prints through serial, so if the battery dies mid performance, I can just plug it in without having to do any crazy re-programming! One thing I noticed, I was carrying it through a dark hallway and the blue LED on the HUZZAH Feather was very bright in the dark. I remember the old ESP8266 + Adafruit LIS3DH arduino code was controlling the on board LEDs. I should look at it again to see if I can pull down the blue LED. Then I'll need to map something onto the accelerometer and start playing some more! Happy April Fools! I didn't see any pranks this year :(
I'm going back to trying to make the whole instrument wireless. I already have the FSRs. I just need my two I2C sensors to be wireless now (Sparkfun LIS3DH and the TCS34725). The IR sensor is connected to the LIS3DH first analog pin. I found a paper where they used the same HUZZAH Feather and an Adafruit LIS3DH, worn by a dancer and sent to Max through UDP: https://www.collin.edu/hr/benefits/cMorgan_sabbaticalSummary_Spr2018b.pdf I played around with the Arduino code that's in their appendix and cut out the bits of code that I don't necessarily need, like controlling the blue and red LEDs on the board. Even though I have the Sparkfun breakout of this particular accelerometer, it still technically works. However, I like how the Sparkfun version prints out its data better than the Adafruit version. I think it has something to do with their libraries. The Sparkfun version prints each axis of data between (1, 0, -1). Whereas the Adafruit prints numbers in the thousands. I am currently having troubles trying to get the way the Sparkfun version to work through UDP. They way it is called to print in serial is not friendly with "message.add" the same way the Adafruit version is. If I have to, I'll use the Adafruit library, but for now I'll keep tinkering away at this. Edit: I figured out how to get the LIS3DH working wirelessly with the Sparkfun library! And it's printing the way it should! It works when I adapted the other LIS3DH code, but I get strange errors that shouldn't be happening when I try to use it with an adapted multiplexer code. Like it said that 'Udp' does not have an end type, for a piece of standard Udp code that's the same no matter what example you use. I know I must have overlooked something. Regardless, now I need to see if I can get the working LIS3DH code put together with the FSR multiplexer. Edit2: I DID IT!!!!!! I figured out how to make both the multiplexer and the LIS3DH wireless in the same code! In the end I think it's more similar to the wireless mux code than the other wireless Adafruit LIS3DH dancer code. Whatever went wrong with the LIS3DH before, isn't happening now. However, the dancer code did provide an example of how to handle multiple messages being spent. I learnt from it that this code needs to be put in place after each sensor (or in the case of the mux, after the whole mux): Udp.beginPacket(outIp, outPort); msg.send(Udp); Udp.endPacket(); msg.empty(); delay(5); I also learnt from the dance code that the "msg.(whatever) can actually be named anything for each sensor. So for the mux I have it as "msgmux" and for the LIS3DH I have it as "msglis". Just when I thought I had the colour detection figured out, I find out that I don't. At first I thought the calibration was permanently messed up because no matter what I couldn't see where the problem was. Then when I made it smaller (only detecting three colours) I realized that it was consistently out of order. For example, if I have it set to only differentiate between RGB, and I set the outputs to RGB, it would instead recognize it in the order of GBR. I realized all it had to do was the order in which the [coll], and later on a [gate] was being updated. Before the coll was first, then the gate. But it should be the gate, then the coll. It was a simple fix of adding a [t i i] to correct the order in which events were happening.
I really hope this is the last time the colour detection is thrown off. Now I just need to figure out what to play! Today I plugged in the the GLOBE and it wasn't recognizing any of the colours properly. I tilted the ball slightly and it is doing a lot better, but I shouldn't have to worry about getting the ball at the exact angle needed to get it to work. Now I have to figure out a way to calibrate the reference colours for the colour detection, or else it just won't work consistently.
I figured out that the insert message does work for updating the the [coll]. The only thing is the coll then grows to be very big and long because the former messages does not go away, they just get pushed farther down in the coll while the updated messages take their place in the list. I don't know if there is a maximum size that a coll can be, so every once in a while I should open the calibration text file and delete the extra lines. Or have it always open to a default with only 7 list items before calibrating. I liked Timo's strange actuator patch and re-mapped the FSRs to that instead. It sounds better with the additive synth for the IR sensor, than the [bowedbar~] object did.
It hit me that I was overcomplicating things the way I was differentiating between RGB. If I am just to select whichever one is a higher value, then if I'm only using RGB, then it will tell me which it's sensing. I can't believe I didn't think of that earlier. Maybe because I was already trying to figure out how to get at least one more colour detected, my mind bypassed the obvious and went straight to the more difficult, convoluted method. https://cycling74.com/forums/help-urgent-compare-3-values-and-export-unique-message This is fine for just detecting RGB, but it gets more complicated when trying to recognize other colours, like orange, yellow, and purple. I went back to the previous example posted in the forums that does a comparison between the colour on the USB camera to colours stored in a coll. https://cycling74.com/forums/max-msp-colour-detection-help-needed It was when looking at this example that I realized that either the way my data is scaled, or the way the sensor works, colours with red-ish undertones are not as accurately represented in the jitter matrix and [pwindow] than the greens and the blues. This has been going on the whole time, not just with this example. A way around this is to record the values I am getting for all of the actual colours, whatever they may be, then store it in the coll to compare it (rather than using the true colours coming directly from the sensor). For example, when my bright red is detected, it comes off as a purpley/magenta colour in the [pwindow]. I would then take those values, and in the coll label it as red, even though those values are technically not red. I tried it and with much experimentation I am able to get, red, orange, yellow, green, blue, purple, and off. Although, once I move out from my basement suite in Calgary, "off" will look different because at the moment it has the stored value of my desk colour. I should probably figure out how to make a bottom so that "off" stays consistent. This coll method was also difficult to do because the more colours I added to the coll, the more likely I got false readings. Also my paint chips have different shades to them, and it was difficult to figure out which was the best shade to sample in order to get the least amount of false readings, and to have the most amount of correct readings for each shade per colour. I found that the lightest shade of each colour, except the orange, worked the best. For the orange, the second lightest shade was the best to sample. I manually sampled the colours, meaning I connected a message box, put the colour under, disconnected the message box, then added the RGB values to the correlated listing in the coll. Down the road I would like to figure out how to sample colours seamlessly on the fly. But in the coll helpfile I can see that you can add to it with the "insert" message, but it does not replace the existing list; it only adds another line. This may be easier done with just message boxes for each item reference for the sake of flexibility. Now to add the whole rainbow to my demo patch! I started up the instrument today to find that everything I figured out last night with the colour recognition is not working properly. I'll redo it, but if it goes wonky tomorrow, I'll forget about it and try something else with it. I realized that if the ball shifts in it's stand, then it messes up the colour sensor readings.
I also found something similar here: https://cycling74.com/forums/max-msp-colour-detection-help-needed I'll first figure out my FSR mapping and then maybe come back to this after. I've mapped the FSRs to the chromatic C scale. I'm using CNMAT's [bowedbar~] object to make them sound kind of like a marimba-like instrument. At first I really liked the timbre of it, but now I'm feeling like it doesn't quite work with everything else. Maybe I should play around with it to make it sound different. Or figure out another simople synth. I added electrical tape to the two FSRs that bleed into each other so that I can tell by their texture which ones they are. |
Welcome!If you are looking for a summary for my Masters thesis, it is here. Archives
November 2022
Categories |