After writing a video playback engine in C, I got a taste for it, and decided to go after the other major component that makes up AI VJ, the live audio BPM detection engine!
And I succeeded - with some suggestions from AI. Our new engine is 200x more CPU efficient, and can detect beats in a range of 80 to 180 BPM.
Plus for those whose music is edgy, or super fast, such as that of one of my most longstanding users, it is now possible to extend this range, or move it anywhere between 50 and 250 BPM! There's a neat slider for this now under settings!
(for optimum results keep the window at a width of 80, though it does work for larger ranges, and by default we ship with a window width of 100).

That is a much greater range than most DJ software offers even for offline / whole file analysis! AI VJ now manages to correctly identify most over-150 BPM music that Virtual DJ pegs somewhere at 75 to 85 BPM.
It should lock on within seconds (max about 15), and so far I haven't found many mainstream tracks yet for which it does not work in the end (it has some problems with "I adore you", by Hugel, due to the 160 BPM snare). Though for a few rare cases it takes up to a minute to find the right BPM.
Naturally songs with long wavering intros without a fixed rhythm will take longer, but not even a human unfamiliar with the song could do those faster, as the info simply isn't there. Luckily this isn't a problem with most DJ styles, as intros are often skipped.
I had not expected to be able to push the envelope this much further beyond what is published in the academic literature. And all this simply by taking an empirical approach, and testing various approaches and additions with both synthetic data and real songs.
Part of our secret is having six bands of music instead of our previous 24 (less is better sometimes), and applying regressions to the output from the Fourier transformations. One regression that locks in the BPM ever closer, and another that is on the lookout for an angle that breaks out of the first when change is happening. This last trick results both in faster changes, and a correct response to the subtle BPM changes DJs like me like to do.
There's more to our approach, such as having four detectors running in parallel, for windows of different sizes, that direct those below, but we were doing a simpler version of that already.
Either way, enjoy, and please report any issues! But remember live BPM detection is still orders of magnitude harder than doing it with the whole sound file available for back-to-front analysis, so don't expect miracles!
Several bugs were fixed, and more small improvements made:
- The red for unowned DLC was a bit too strong, reduced it to a grey. Though in menu icons it is still red, though that's ok
- A few minor tooltip fixes
- A significant performance improvement was achieved due to keeping the audio streams within the C code, and thus putting a lower load on the C# garbage collector
If you reported (other) bugs, we're keeping a list and working through them! Please keep reports coming! We won't know if you don't tell us (best place to do so is in our Discord)
Feature requests & bug reports are welcome. Either here or on our Discord!