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…