Yeah I would think so. Or at least do better than 50%. (It literally has half the files right)
In the p playback subpatch I’m triggering files from a polybuffer~ that contains the entries that are in the fluid.kdtree~. The only thing is that I’m doing it as a real-time process (in p audioAnalysis). Both were created by the same onset detection and descriptor settings, but it’s likely that doing it again missing a couple samples off the start of the file that makes a big enough difference with the windowing to not match.
As I said, I didn’t sanatize the fluid.dataset~s at all either, which may exaggerate certain things(?).
I don’t think the fluid.bufcompose~ error is related because it’s after the matching process. Basically the fluid.kdtree~ spits out the match, then I put together a new buffer~ (in the bottom left corner) which is what would subsequently query a second fluid.kdtree~ that contains the actual corpus of samples. So I’m just concatenating the descriptors from the real-time analysis with the predicted descriptors that follow.