After achieving the first goal to turn an effect on above a certain fret and turn it off when below this fret as outlined in Blog #3, I have to admit that I struggled a little bit figuring out my next steps. Luckily, my supervisor and I were able to schedule and hold a meeting last week and it really helped me finding out what to do next. This weekend was all about coding and refining the code that I had up until then.
One of my problems was that the sensor data I received in Pure Data was fluctuating a lot in a quiet volatile manner which made it not ideal to control parameters like delay time or feedback amount for example. My supervisor suggested applying a kind of filter that smooths the readings. We decided on the moving average method. Based on this method, I added some lines to my code so now the Arduino takes ten samples of the distance readings of the ultrasonic sensor, sums them up and then calculates the average by dividing the sum of the ten samples by ten. I then use the average value of ten incoming samples for further computation and MIDI conversion instead of individual values. I tried it out and at least in the serial monitor of the Arduino IDE, the readings are less volatile. However, I still have to try it out in conjuncture with Pure Data and actual audio effect applications. The readings are especially smooth using integer values which I did at first. However, I fear that I might need float values in my further computations, so I changed the average filter to work floating point numbers. However, maybe integer values may be enough – so far it is impossible to tell for me.
Next to the moving average filter, another measure taken to smooth the incoming MIDI data was to send the MIDI data less frequently than the sensor outputs its readings. Using the millis() object, I programmed the Arduino to keep of the time since the program started and wait 20 ms each time before sending MIDI data to my laptop. Of course, the delay should not be too long to ensure that the parameter changes of audio effects controlled by the incoming data are still smooth enough. I think it works but as it is the case with the moving average filter, I still have to confirm the measure’s positive impact in conjuncture with Pure Data and actual audio effect applications.
Additionally, me and supervisor also talked about ways to improve some problems that I was experiencing in Pure Data. The first problem was massive latency issues, so we talked about ways to reduce the latency in Pure Data. However, as I focused on the coding aspects this weekend, I did not come round to that part yet. Additionally, there were constant clicks when I used the MIDI data from the ultrasonic sensor to alter parameters of audio effects in Pure Data. Luckily, my supervisor could help me out: apparently, I (unintentionally) implemented a kind of true bypass solution that comes with its characteristic popping noise when turned on or off. With the sig~ object and a lowpass filter lop~, I now first convert the control (numeric) signal to an audio signal and then filter it which should remove the pops.
