Pre-processing for (Training for real-time NMF)

[rodrigo.constanzo]

@tremblap

my last hypo on this was to no clean them - you should process what you get!

I can give that a spin too. It’s just really really noisy, so I imagine(d) that that would unfavorably skew the dict creation and matching (using up some of the precious 33bins on garbage information).

@tremblap

So my idea is super simple: to take the (amazing) attack detector I have done in time domain, and take that to grab the next out from nmfmatch. That should give you an array of RANK values. Check the index of the largest number, and that should tell you which one it is more likely to be. It might be that you have to wait the 2nd nmfmatch out after the attack detector since it is so quick.

Does it make sense?

I’m doing that in my patch now. I added a variable delay in there (10ms seems to work ok), but it doesn’t really work. The best working version was something @jamesbradbury got working using fluid.transientslice~, which is slower than the fast onset detection. But in what I have now, it’s correct only through random chance. (some dicts do match more consistently than others)

What I was hoping for with the “onset flag” feature request was to remove the slop of trying to line up a parallel onset detection algorithm with the deluge coming from nmfmatch.