At first I was thinking "this isn't a big deal, Atari Jaguar CD did this back in 1995 on way less hardware," but then I realised it was a hackathon project and now I'm really impressed at how far they got in that short frame of time!
Pretty boring if it's just FFT based. I'd love to see music visualizations make use of more sophisticated musical feature detection, like polyphonic note recognition or tempo/rhythm analysis.
Given the nature of the project, a hackathon, sticking to the last computed FFTs and a notion of time was all we need to play with nice shader effects.
I'm currently playing with tensorflow on my spare time.
I'd like to use a neural net to find interesting features of a track and inputting this to a shader. That's what I would do if I had another go at it.
Cool work, but note that a 1024 point FFT isn't really sufficient to visualize music. At 44.1kHz, the lowest frequency you can resolve is 43Hz. Anything below that will be folded into your DC component. Your bass response is mostly going to be overall volume, rather than beat.
Most music is mixed not to have any useful spectral information below that frequency anyway. And if you want beat then a better thing you can do is look at the half-wave rectified difference between the sums of two FFT frames (with optional lowpass). This results in an onset graph that is the basis for a lot of real-time beat detection algorithms.
There is definitely an impact on the battery. The FFT part is well optimised (thanks to the Accelerate framework). What is costly is mainly the shader... and it really depends on the shader. A very simple shader is usually less than 5% of the GPU usage (according the Xcode Instruments, and on a recent iPhone). However if you do a lot in your shader it's going to be much more costly.
