# SC: Server lookup for KMeans and KDTree

**URL:** https://discourse.flucoma.org/t/sc-server-lookup-for-kmeans-and-kdtree/381
**Category:** Pre-Release Toolbox2 New Ideas
**Created:** [December 19, 2019, 10:41pm UTC](https://discourse.flucoma.org/t/sc-server-lookup-for-kmeans-and-kdtree/381 "2019-12-19T22:41:06Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![tedmoore](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tedmoore/32/439_2.png) [@tedmoore](https://discourse.flucoma.org/u/tedmoore)
#### Post date: [December 19, 2019, 10:41pm UTC](https://discourse.flucoma.org/t/sc-server-lookup-for-kmeans-and-kdtree/381/1 "2019-12-19T22:41:06Z")

</div>

Greetings,

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:

```auto
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?

---

<div class="post-metadata">

### Author: ![tremblap](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tremblap/32/5_2.png) [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [December 20, 2019, 9:53am UTC](https://discourse.flucoma.org/t/sc-server-lookup-for-kmeans-and-kdtree/381/2 "2019-12-20T09:53:50Z")

</div>

@weefuzzy was thinking of a few helpers along those lines indeed, maybe in kr though. I’ll let him reply directly.

---

<div class="post-metadata">

### Author: ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)
#### Post date: [December 20, 2019, 11:12am UTC](https://discourse.flucoma.org/t/sc-server-lookup-for-kmeans-and-kdtree/381/3 "2019-12-20T11:12:41Z")

</div>

Hi @tedmoore,

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.

---

<div class="post-metadata">

### Author: ![groma](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/g/a4c791/32.png) [@groma](https://discourse.flucoma.org/u/groma)
#### Post date: [December 20, 2019, 10:57pm UTC](https://discourse.flucoma.org/t/sc-server-lookup-for-kmeans-and-kdtree/381/4 "2019-12-20T22:57:03Z")

</div>

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…
