I guess if you want equal weighting, you can just use 36d instead of 12d, with the same time series involved. Or maybe something more AudioGuide-esque and have equally weighted macro-frames to capture the morphology more clearly.
I was wondering about this, and I guess this is something you tried to explain in the last geek out. So with this approach, you may still query for pitch, but everything that was dismissed/deleted will create a malformed query now?
I guess this is a workaround to having pitch “default” to being low, and centroid “default” to being nyquist or whatever it was you did.
I like the idea, but then wonder about how to deal with that in terms of interface (spamming errors, any errors?, etc…).
Out of curiousity, how much of the testing has been done with arbitrarily-lengthed segments? As @tutschku (and I) have mentioned, I find it next to impossible to gauge “timbre” between a tiny sample of audio (100ms) vs 3seconds+ fragment of “music”. A lot of the examples segment into these big (and small) chunks, and I can’t really tell since I don’t “hear in means”.
Is this just conceptual or is there some technical benefit for (presumably) keeping dB and MIDI in their “natural” units?
Yes please!
Some of the patches are easy to swap out and change bits, but most of them presume fixed dimensions and features, making it very difficult to test with different amount of features/stats (since all the query/flatten stuff has pre-baked indices).
Interesting. Do you mean using something like what @spluta has been doing by navigating a corpus space (ala sandbox3) with “live” bass audio?
By “passing on the pitch”, do you mean applying the pitch to the target? So you find the nearest match for loudness/timbre in the normal ways, then literally map the pitch of the source to the matched grain/segment?