This looks interesting, as I am also using this library for lighting effects. I'll give it a try in my application.

But this other PR is oddly similar: #392. I guess multiple people wanted this and developed it independently?

@phatpaul I find it hard to tell if the other PR is completely independent (it doesn't expose a command line parameter, for example). I can't test the other one the way I use it though (I rely on the command line), but it's also just one giant commit so maybe there are slight differences in what they do/how they work.

I do notice that the other one missed the hardcoded > 206 in beattracking.c though, but maybe at the same time it has that subtle thing I missed in mine where it sometimes misses beats on < 60? C isn't my forte so it's very possible I missed something.

The only things I can say for sure are:

• I've been using aubio with my PR for over 1.5 years now, without issues
• I only rebased my PR because it didn't compile with ffmpeg 7 anymore. From short testing everything seems to work the same, but I'll be doing a more thorough test during this weekend (with actual light fixtures connected).

I've been comparing the 2 PR a few weeks ago and finally got the time to try and add one of them in my project.
Correct me if I'm wrong, but you can't change the target tempo without recreating a tempo object (and thus restarting detection), right ?
The other PR offers getters and setters, which is really appealing!

Tested my things over the weekend, behaviour was still as expected.

@quentinhayot

Correct me if I'm wrong, but you can't change the target tempo without recreating a tempo object (and thus restarting detection), right ?

This sounds correct. I run 10 or so aubio-track processes in parallel and switch which one I'm using as a beat source. Setting/changing them on the fly was never a requirement for me. It's probably not too difficult to add to this PR though? If you (or anyone) creates a patch for it I can add it to this PR, or a maintainer can add it regardless.
That said, I don't really believe in monkey-patching PRs to be 'perfect' straight away, as long as they don't break anything and are still an incremental improvement. Imo, the real issue here is aubio maintainer(s) not doing/saying anything about either of the PRs for well over a year already. I'm totally fine in upgrading my PR branch to a fork if a maintainer comes in and says "we have no interest in merging either of these ever" and of course at that point I'll also add the get/set stuff.

Good to see other people interested in that as well. I have the same use case, lighting control, and needed to work around a problem where aubio would jump between ~178 bpm and ~120 bpm on some of the tracks I tested with. (As far as I can tell, when it stops detecting beats during more quiet passages, it would default back to 120bpm.) I wanted real-time updating of estimated bpm, so I implemented it that way. The PR is more of an afterthought, which is why the description isn't great and why I seem to have completely missed this existing one.

My PR only refactors the bpm-dependent code into aubio_beattracking_set_target (which should really be called aubio_beattracking_set_estimated_bpm or so). IIRC the rest of the algorithm looked like it should work with a wide range of bpm values. I ignored the 206 bpm limit because I don't need it to go that fast, and had some concerns about breaking the algorithm. And I didn't even realize parameters can be set from the command line because I'm using libaubio as a library.

@barbeque-squared regarding the missed beats: That one is interesting because my application also misses a single beat occasionally. It fairly consistently misses a beat every "few" (maybe around 100? 200?) beats. I originally suspected my code, especially since it consistently reports 1-2 bpm faster than the DJ controller. But maybe this is the algorithm in aubio not working well for bpm values other than 120?

TBH by now I'm treating my PR as essentially abandoned. I'm not sure I will find the time to develop it further.

I wanted real-time updating of estimated bpm

Ah yeah I didn't get that from your PR. I don't really use the actual/estimated BPM anywhere, but I know most 'real' lighting controls do use it. Nice use of aubio though!

But maybe this is the algorithm in aubio not working well for bpm values other than 120?

Probably. Your +1/+2 observation is also interesting, would definitely explain why it appears to miss a beat every "few" beats (with "few" being the bpm). I don't know where the +1/+2 is coming from, but if it's doing that regardless of bpm, that would explain why the skipping is (to me) so much more noticeable on 60bpm than it is on 200bpm.

Looking back on my PR, I wonder if my window size adjustment is wrong. Once I have some time I'll probably change it and also add library functions to this PR.

@tqzamf I have that +X bpm issue too. The actual error in the reading varies but will always be the same for the same real bpm / target bpm combo.