How to use (B-Track for) beat detection/prediction with JUCE?

I plan on experimenting a bit with beat detection/prediction and JUCE. For this I found B-Track (https://github.com/adamstark/BTrack), which looks promising, but I can’t get it to work with JUCE. Is there anyone who knows how I can get this to work?

I currently have fftw3 and samplerate set up as external libraries in the Projucer (obviously I have both installed as well) and added the B-Track source code to my project. The compiling succeeds, but whenever the fftw_execute is called, I get an EXC_BAD_ACCESS. I basically create the B-Track in the audioDeviceAboutToStart, after which I try to process the buffer in audioDeviceIOCallback. Could the multi-threaded nature of JUCE be a cause of this issue?

If there is anyone who has used a similar framework with JUCE, your experiences and suggestions are welcomed as well!

EXC_BAD_ACCESS means that something is using a pointer to memory that doesn’t represent an object. Try enabling address sanitizer in Xcode, and rebuilding your project, and you should get more information about what’s going wrong. Alternatively, you can try posting a screenshot of Xcode after the crash here and we might be able to help.

So, I got it to run under Xcode with the address sanitizer, what would be the right information to post here?

Another interesting thing I noticed is that the program crashes slightly earlier udner Xcode (with address sanitizer activated), than it does under CLion.

// window frame and copy to complex array, swapping the first and second half of the signal
for (int i = 0;i < fsize2;i++)
{
	complexIn[i][0] = frame[i + fsize2] * window[i + fsize2]; //<-- Indicated as crashing point under Xcode
	complexIn[i][1] = 0.0;
	complexIn[i+fsize2][0] = frame[i] * window[i];
	complexIn[i+fsize2][1] = 0.0;
}

// perform the fft
fftw_execute (p); //<-- Indicated under as crashing point under CLion debugger

Address Sanitizer will normally print a whole bunch of stuff to the console pane after a crash. That’s where I’d start looking for clues.

It’s probably also worth double-checking the values of fsize2 and i at the point the program crashes. Will complexIn, frame and window always have room for 2 * fsize2 elements?

@YetAnotherGuy – I’d be very curious to hear if you had any success with this. I’m attempting to make a beat tracker in JUCE, and BTrak is the strongest lead I’ve found so far. Just trying to digest the code and accompanying paper at the moment!

Same here, I’m also interested to hear of any progress!
@MartinT have you ended up making any?
I was about to give it a go a few months ago but wasn’t able to start properly due to some other things unfortunately. I will be posting any progress here: https://github.com/glynternet/juce-btrack

@GlynHanmer – I’ve so far made something very simple that tries to detect the tempo of an incoming signal, and displays that value live. I’ve been testing it out with a drum machine, but currently I’m getting wonky (but consistent) tempo estimations. I think I’m on the right track, but doing something wrong somewhere. I haven’t fully picked apart all the code yet, but have a feeling it’s something to do with buffer sizes.
Here’s the github project: