I was thinking about what's keeping Pico-8 from being a popular platform for scientific computing and high-end DSP ... and I realized: I can't think of a single FFT library for Pico-8! That must be the reason. So I wrote one:
There are some comments at the top of the cart code on usage, if you want to copy/paste this into a project of your own for some reason. It's not too slow: you can do about 400 length-256 real FFTs per second, which is enough to get up to some audio shenanigans. (See next cart.) You can use the left/right arrow keys to switch modes between DFT, complex FFT, real FFT, and DCT in this demo, but be aware that if you happen to switch to DFT mode - it is sloooooooow and you may have to hold a button down for a while to get out of it. (DCT is also slow but ~3x faster than DFT.)
If you want to try out a somewhat-contrived audio application, check out this cart:
If you drag in a short Pico-8 friendly raw PCM file (max ~6 seconds, use Defy to do the conversion) this cart will play it on loop, and boost/cut frequencies according to whatever curve you draw with the mouse. All the scaling is linear, which is not very natural (log scale for both frequency and amplitude would be more conventional), but you can still create some obnoxious notches and resonances. Give it a try!
Now that I think about it, the make_hann() and make_stft() functions from the demo cart might be useful to other cart authors as well - those take care of the overlap-add process for FFT resynthesis in a fairly transparent way. I've added a comment to make_stft() that should hopefully help with usage. It handles windowing and overlapping in a simple but fairly inflexible way. There is no attempt at any kind of fancy phase consistency logic. (The demo should probably be windowing the synthesized audio as well before summing it - maybe I'll fix that eventually.)
Changelog
2022/08/29: added DCT and inverse DCT functions. These are very short, faster than DFT, and may be a good choice for some applications involving lossy compression of real-valued data.
Pretty amazing what having an audio output enables!
I think with similar effects and audio routing to RP-8 but 8ish channels of sample playback instead of the synths, should be pretty doable. Give it a more standard tracker interface and perhaps that’s interesting for composition?
That’s the best idea I have at this point for a general purpose music production type cart, anyway. Might be some issues with CPU vs sample storage space tradeoffs and/or song saving and loading time.
Not sure yet if this FFT code has any practical Pico-8 application.
@Waporwave Interesting - I'm not quite sure what sort of workflow you're proposing. Is it:
- Load a high-sample-rate sample into Pico-8
- Use this library to brickwall filter it at 5.5kHz
- Preview result
- Save filtered result
? Or did I misunderstand and you were suggesting something else?
@luchak I think that's what I was suggesting. The thing is converting the samples from full quality to p8 changes them a lot. I think it was you who was telling me about like high frequency problems and stuff in the discord some time back. I'm not sure how great it would work, but being able to edit and preview in pico 8 would let you hear what it would actually sound like and adjust.
Omg. I'm a physics graduate student with a focus on signal processing and this just gave me goosebumps. I can't wait to look through this code.
Great! The actual FFT code isn't too bad, I think, although I'd love to try out an iterative approach at some point. The test harness code is a mess. :)
The fun thing is that it appears to be possible to run STFT in parallel with the RP-8 sound engine.... Though a 2x overlap seems to get you pretty close to 100% CPU, so all my experiments so far have used non-overlapping windows to leave time for graphics and other tasks.
[Please log in to post a comment]
