|
I had an idea for more pictures in the dark in order to really show off the cool colours from the LEDs. I feel like I spent a lot of time yesterday practicing for the hamster stand piece, so today I decided that each day I'll start with practicing the twister mat piece first so it doesn't get neglected. I think the tendency to practice the hamster stand piece more is because its mapping is more similar to that of a traditional instrument; it has exact pitches and timbre to worry about and a historical understand of what its sounds should sound like. AKA There would likely be more understanding and criticism from an audience about what would make it sound "good".
I found that instead of trying to memorize which FSR is mapped to which specific note and trying to think about music theory and chords while I am playing (something that I can't do very well with violin either), it is easier to think of how many FSRs are in between the two that I'm playing. One FSR in between are the easiest to visualize and they are thirds. Then I think about two FSRs in between, then three, ect. Thinking this way helps me make more "musical" decisions in the moment than to think about perfect 5ths, 4ths, 6ths, etc. So today with the twister mat practice I realized that it is difficult to remember exactly what is mapped to what with the accelerometer and the IR sensor; it's different for each colour. I realized that some colours, like green for example, used only the X axis of the accelerometer, and others used only the Y axis. This is more challenging to remember, so I changed it so that whenever there is only one axis mapped, it is the Y axis. I have a preference towards the Y axis because of how the FSRs and IR are oriented. I also realized that some playing techniques are more preferable than others depending on the sound engine. For example, I don't like how it sounds in the yellow when the ball is upside down. But I love it when the ball is upside down when it is green. I like to roll the ball around on the ground a lot when it is red, but not so much with the other colours. I dug deeper into why the green on the twister mat has been so difficult. I found that it is being recognized fine, but the gate, controlled by putting a threshold on the clear, has been closing before the trigger for the green can get through. Then it would not change back to green once it can get through because the green's onebang would then need to be reset (because it already fired off). I improved the situation by
1) Add a [pipe 100] to the integer that turns off the gates (but left turning on the gate at its regular rate. 2) Have the "off" always resets the green [onebang], even when it is turned off for therest of the colours. Now it seems a little too easy to accidentally trigger green when "off" is selected. But that's better than it not being sensitive enough. Luckily the sounds on green are my favourite for this piece. And with practice I know tricks to help prevent it from misfiring so it shouldn't be that bad. Since the colours on the twister mat are so dark, I added a brightness function to turn up the colours a bit. Basically, you know it's where it needs to be if when you sample white, it is white. I practiced on the hamster stand patch a bit too. I tried everything I could think of to reduce the latency that Graeme noticed on the FSRs, but I couldn't make any noticeable difference. It's funny that I'm not sure if I noticed any latency before on FSRs, but now that it was pointed out to me I definitely notice. I checked with the old demo patch and I think the latency is there too. I've been working away trying to make the colour detection even more reliable. I added [onebang] to the colour detection and delays on resetting the [onebang]s so that it doesn't misfire as often. In general I'm still having the most troubles with sensing green on the twister mat. I realized the best playing technique with the twister mat is to roll the ball around to the colour I want, and once it is sampled, then lift the ball up off the ground to prevent it from accidentally selecting the wrong colour when I don't mean for it to.
I noticed that it is difficult to audibly tell how the accelerometer is affecting each colour section. I went through each and decided to make sure that the IR is very noticeable. That way I'm mostly focusing on the IR and FSRs during the performance and I just let the accelerometer do its thing, whatever that may be. I'm considering maybe putting another filter on just before the master gain so that there is one unifying parameter for the whole patch. Not sure if it is a good idea or not. Oh, and I'm allowed to have my brother be a guinea pig. Yay! I took out the function1 in the Arduino Code and made the "clear" print through both serial and UDP. It really does act like a proximity sensor and makes it simple to get the colour sensor to ignore sensing ambient light. It will be helpful in that I don't have to sample the ambient light for my twister mat piece, and make it so it more accurately recognizes green. (hopefully, I still need to test).
I also realized that in order for the data to print through serial, the ESP8266 has to first make the wireless connection. The router can be unplugged after the connection is made and the ESP8266 can still print out the data through serial, it just needs the initial connection. This was the same with TRAVIS I. I figured out that what is happening, since it couldn't connect to the network, it was stuck printing out "..........", which is what it is supposed to do. If I commented that part of the code out, then it works fine through serial without having to first make a wireless connection. The only downside is there is now nothing to show me that it is clearly a wireless issue. However, the dots wouldn't show clearly in Max regardless, so it doesn't make a difference for how I'm using it. Since I took out function1, I renamed frunction2 as function1, and function3 as function2. I am almost finished the patch for my second piece with the GLOBE. Last night I was playing around with it on the twister mat some more. I noticed that it had a tendency to trigger red more often, which was fixed by sampling the ground as "off" and ambient light as "orange". However, the ambient light was very dark, and the green circles on the twister mat is also very dark. So that made it accidentally trigger "orange" when I actually meant for it to trigger green.
I slept on the problem and I remember that there are three functions in the arduino sketch to drive the LED's. They are based on another value coming off of the colour sensor I think it has either to do with proximity or overall light levels. I can't remember, got to check again. But basically it allows the LEDs to turn off if the sensors "sees" black, and for them to maintain their previously sensed colour of the sensors "sees" ambient light. If I can modify the Arduino code to spit out that value, I could use it to program the colour detection similarly, where it will sense a colour if it is close and ignore if it is ambient light. I also thought it would be good to take out that LED turn off function in the Arduino code to better reflect what is happening with the sound. 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.  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. |
Welcome!If you are looking for a summary for my Masters thesis, it is here. Archives
May 2020
Categories
|
RSS Feed
