Maybe this will help someone who’s trying this as well. The first algortihm posted here had a slight flaw, in that supercollider silently stops computing all of ~points when it encounters a problem. Maybe memory, maybe for other reasons. So the number of results returned were about half of what is expected. If there are 346 points returned by a fluidbufnovelty slice, doing a 4 nearest neighbour search on every point should return 346, but here it returned only 165. Consistently too.
Since kNearest is going to execute as an asynchronous process with a callback, the way to sequentially run through all of ~points would be to call kNearest within it’s callback function. Also, it has to be encapsulated in a Task, so, for some reason, point.setn inserting values into the Buffer completes.
~chk={
arg array;
targetpoint= shift (array);
Task ({
point.setn( targetpoint);
~tree.kNearest(point,5,{
<do compute>
~chk.(array);
});
});
Task.start
}
~chk.(~points)