Ok, so first let me apologize - the last time after downloading the latest version, I didn't actually try binding any keys, but just checked to see if the frequencies had been made accurate.  Based on experiences with the previous versions, I felt accurate frequencies were necessary for my own sanity when debugging.  However, the way the app records peaks now for key presses works really well!  I gave it another test and was able to get an octave's worth of notes to register as separate notes.  So again, I apologize for not giving it a fair shot.  It does seem to be usable for me now.

I'm a little confused why you're brushing this off as a minor bug, though - the Hz aren't just off by an offset, or by some slight inaccuracy - the value could be off by a factor of 10, or probably 100 if you went high enough.  They don't seem to track Hz at all.  Which, fair enough, isn't strictly necessary for binding keys, which is the purpose of the app, but why call them Hz when they're not Hz?  I found it very confusing when trying to make sense of my key bindings.  Obviously I don't know the inner workings of the app, but I would think the APIs would make it easy to match with real Hz?  If it's difficult or impossible for some reason, though, at this point I would recommend simply hiding the Hz data from the user, because they don't really need it to bind keys thanks to the new interface, and it's very confusing to someone trying to set up keys by their actual frequencies.

As far as my personal results and why they've been so confusing, the button presses I've got working have some strange values - the peaks for my octave (starting from the bottom on G3) are 71, 75, 117, 121, 124, 113, 116, 120.  So it starts low, but the value jumps up on the third note, then jumps a little back down on the 6th.  I'm not sure why that is - it could be that my instrument has a messy tone, but tuners don't usually seem to have a problem identifying the notes.  I'll sometimes see the peak that matches up more closely with the previous notes within the spectrum, but it gets superseded by another peak. It's previously caused problems when these ranges start to overlap, so that multiple notes are trying to press the same key, but the new multi-peak recording interface has somewhat resolved that problem.  At this point I guess I should just treat it as a black box and not look inside, but the engineer in me wants to figure out why these values are so unexpected.