EDIT: in the great rush to get this out before the party i managed to compile this with 11025 Hz/1024 🤦♀️ The upside is that there was less difference between this and the older version used for streaming!
v0.0.5 — 44.1 kHz 11 kHz, 1024 buckets
What's new
- Rebased on the latest version that has important fixes wrt CLI argument handling
44.1 kHz11 kHz, 1024 buckets (this seems to give the best data for now; with less buckets, the lower end of the bass gets unreliable)- Fixed issue with capturing non-default loopback devices on Windows
fftandfftscan now sum frequencies between two bucket indices
Important Notes
-
For the FFT feature to work you need to start it with
--fft -
On Windows, use
--fftuseplaybackdevicesto capture the loopback. Double-check the console output you're not accidentally capturing your microphone when running without it! -
On all platforms, for your input device, set it within the OS to 44100 Hz, because resampling produces artifacts every 3-4 seconds or so. You can do that in Audio MIDI Setup on macOS for example. Windows should default to 44100 Hz (based on my very limited testing), double-check the console output and adjust if needed.
-
Check
tic80 -hfor more options.
Known bugs
- Bounds checking for the summing feature (see below) only properly implemented in lua
- If resampling kicks in, expect artifacts in the data in every 3-4 seconds
- When first running your program, leave it running for about 20-30 seconds, as it turns out initializing the peak normalization takes time and initially all buckets are close to 0. This only happens on the first run after TIC-80 started.
Documentation
Two functions to use:
fft(start_freq, end_freq=-1) gives you the data with peak normalization (volume independent) in the given bin (or range) where the number should be between 0 and 1 except it's sometimes slightly more than 1. Will try to track down this issue another day, but afaict this is also present in Bonzo.
ffts(start_freq, end_freq=-1) gives you the data with peak normalization and peak smoothing in a given bin (or range) with a factor of 0.6f which seems like a sweet spot but may tweak it in the future. This data does seem to be accurately between 0 and 1.
As always, thanks @TheNuSan for the help.
All feedback appreciated!
Full Changelog: v0.0.4...v0.0.5
