Uses the pulse sensor that Yury/Joel made; currently I’m mapping pulse to amplitude of the sin wave (very nifty sin wave using Daniel Shiffman’s equations) although, as usual, I’ve decided to go down the (shiny!!!!) HSB colourmode. Did I mention how much I love HSB???
the processing-recieve code is basically a serial response – it sends strings of ‘b’ (heartbeat) ‘p’ (peak value) ‘t’ (trough value) and ‘d’ (detect) the original one that comes with the sensor is a lot more complicated since it has a ridiculous number of ints(inData) but I cut it down to 4…. and even so, I didn’t use all the variables (compare it to the arduino code, so many ints!). I guess I just wanted to make it easy to edit with, because it’s not really perfect/to my own standards. There’s a bit of jerkyness when the pulse beat drops/rises and debouncing doesn’t really help – it makes it worse since the delay increases the change in amplitude and the coding is kinda hacky – I mapped it as amplitude = float(inData)*1.0f/10. I needed to convert the raw sensor data to frames, but that resulted in something like 81-113 fps/amplitude which made the graphing go crazy, so I divided it by 10 so that it would stay within processing’s 15fps standardisation.
I think improvements would be – gradual the change ‘b’/time(?) since right now ‘b’/beat is a boolean, and the moment it turns true it just snaps the graph (no transition). Map amplitude as ‘p’/peak – ‘t’/trough = drop average, which will give a smoother, more consistent rhythm and if also really *really* think this would be much easier on OF; since I could write it as sin(of_time_elapsed) instead of multiplying frames, dividing it etc etc there’s other things I could change as well, like using xspacing (tighter xspacing for faster heartbeat) and using period. Another thing that might be cool would be to use mimin library and set height as a sound file, so the yvalue will be a ‘note’ on the sound map.
Download code here: http://www.mediafire.com/file/2e9za6wckhb8whz/pulsesensor.zip