getPoint FluidDataSet

Hi all,
I am trying to understand what is the issue with the attached patch.
As I wrote in the comments, the first evaluation seems to give the expected result while when you re-evaluate the result becomes unpredictable.
Thanks to point out where is the issue.
Y
getpoint.zip (8.8 KB)

Hi and welcome @yannics!

I think what’s happening is that instructions aren’t executing in quite the order you want, because of the buffer read being in the action for getPoint and the s.sync only affecting getPoint rather than both getPoint and getn. Things end up being uncertain because a callback that triggers getn could arrive either side of a call to s.sync so that the whole loop doesn’t end up with the blocking pattern you want.

This simpler code will do you what you want, I think:

(
// ... re-evaluate here
z=[];
fork{
    ~nearest.do{|n|
        ~testds.getPoint(n,~tmpbuf); 
        ~tmpbuf.getn(0,1,  {
                    |x| if(x[0].round == ~p[0]) {z = z.add([x[0],n])}
        });       
        s.sync;
        if(n == ~nearest.last) {"done".postln; }
    }
};
)

By just sending the getPoint and getn ‘together’ before placing a sync in he server queue, we can be sure that they’re properly paired.

However, I should point out that this is a really slow way of doing it, precisely because it needs a round trip between language and server for every point. This should be faster and easier to reason about, by dumping the dataset into a dictionary instead:

(
z = [];
~testds.dump{|d|
    d["data"].keysValuesDo{|id,point|
        if(point[0].round == ~p[0]) {z = z.add([point[0],n])}
    }
}
)

(but would’t work with a remote server, AFAIK)

Indeed, I was suspecting something like queuing between language and server, and now the answer is obvious. Thanks for the clarification and for clarity. Anyway, this is a working patch as a draft to check some expected behavior. For now and for my part, your code will do the job.