I’m so happy to have KDTree and KMeans included in the toolset. However in order to make them most useful we really need to have these methods running on the server. What I really want is something like this:
In a SynthDef:
neighbors = FluidKDTree.ar(input_vector, server_kdtree_to_use, k_neighbors_to_return);
where “neighbors” is an array of integers that can be used to look up those vectors or their corresponding information in other buffers (e.g. start location in a buffer, duration of grain–then one could use Index.ar to look up those values and play a sound with TGrains).
I know this is problematic given the paradigm that ids in the dataset are symbols or strings… is there a way around this?
@weefuzzy was thinking of a few helpers along those lines indeed, maybe in kr though. I’ll let him reply directly.
Yes, this is planned. Strings aren’t the sticky issue here. Rather, the challenge is that the commands already run on the server (even though it doesn’t look like it) via the
u_cmd facility. As such, there’s already a
kr for these objects, but it doesn’t do what you need yet. The challenge is working out what a feasible interface would be, especially for classes like KDTree that do more than one thing (or will do) . I hope to have some ideas to bounce off you in the new year.
Yes, as @weefuzzy says we have plans for server-side (and MSP-side in Max) combinations of these objects, which will be necessary for real-time usage. I can see strings being an issue for interacting with other SC UGens, although our idea was that these IDs represent buffers, so we would have another object that can do the mapping. Anyway it is all still on the drawing board…