Threading/blocking on vanilla fluid.dataset~ messages

After getting a lot of use out of the filter messages to fluid.datasetquery~ (particularly once wrapped up in syntax abstraction) in the last update of SP-Tools I got to thinking that it would be great to apply this on a stream of descriptors, and route accordingly.

As in, having a list (or buffer) or descriptors for a given frame/window, and then be able to check if filter loudness > -45 or filter centroid < 90 or more usefully filter centroid > 90 and loudness < -50.

I initially tried to think of some awful thing with chained/parallel vanilla Max comparators and then parsing all the messages so it compares the logic, but that seemed brutal.

I remembered @tremblap mentioning the use of frombuffer direct into a fluid.dataset~, so I decided to try and use fluid.dataset~ and fluid.datasetquery~ as single entry filtering. It works really well, but I’m not entirely sure how the threading is handled here.

None of the dataset-based objects have any threading messages, so I can’t explicitly put them in @blocking 2 or anything. I vaguely remember some mention that they inherit their thread from whatever calls them, which in this case is the higher priority thread. Is that correct?

I’m only frombuffer-ing a single buffer with 8 points, and moving a single column with the fluid.datasetquery~ message as I don’t care what gets moved, only if something got moved. But I’d not want to get my hopes up if this is problematic with regards to threading etc…

Yes. So the important thing (if you’re both mutating and querying something) is to be consistent about the thread.

1 Like