So I’ve been doing this thing in SP-Tools where I use fluid.datasetquery~ on a single entry fluid.dataset~ as a way of applying “real-time” filtering to descriptor streams.
There most common use case is where I parse something like filter centroid > 90 and loudness < -50 into fluid.datasetquery~-friendly syntax and use that to filter out incoming ‘onset descriptors’ where only loud/bright onsets will be passed along, and others will be ignored.
Works great!
I’ve also used the same abstraction on a stream of realtime descriptor data (basically applying the query per analysis frame) to apply a filter to the descriptors going onto a concatenation/mosaicing process. Also works great!
except
For realtime/fast descriptors, having some kind of hysteresis would be super useful, particularly for things like loudness, which can be fluttery around thresholds, making it hard to dial settings in just right.
///////////////////////////////////////////////////////////////////////////////////////////////////
So my first thought was just to build a bunch of parallel Schmitt triggers, and apply them to each descriptor stream. Easy enough. BUT I lose out on the useful utility of being able to apply logical conditions to chains of them.
For example:
centroid 90 60 and loudness -30 -50
Where each independent desciptor goes through its own Schmitt trigger and the filter is only valid when the (sub)criteria of the Schmitt is true, and then the logical condition, in this case a single ‘and’, is also true.
Now again, its fairly simple to build out a few logic branches, like all ands or all ors, but having to code around all the permutations (in Max at least) of chained and and ors is terrifying.
So this leads me back to wondering if I can somehow leverage fluid.datasetquery~ in a similar way.
Obviously it’s not intended for this kind of usage, and my pseudo-workaround of creating single entry datasets to validate multiple conditions is kind of pushing at the edges of what it’s mean to do. But I’m wondering if I can somehow chain a couple parallel fluid.datasetquery~s together, or some other thing to be able to leverage its internal logical condition magic.
///////////////////////////////////////////////////////////////////////////////////////////////////
I vaguely thought about reducing the individual descriptor Schmitts to 1/0 states if they are met, to produce binary strings (e.g. 1 1 1 0 1 or 0 0 1 0 1, as I have 5 such descriptors I’d like to be Schmitt’d) and then building single entry datasets out of them. Where my brain goes to mush is that I don’t know how to build “time” into the equation here.
Maybe somehow doubling up the entry length so each binary pair represents a change in state where:
loudness > -30 = 1
loudness < -50 = 0
Therefor the “loudness” entries in a dataset would be 1 0 and I would then query loudness = 0 1 and if it’s true, it would return a 1, letting me know the Schmitt criteria has been met.
So fleshing this out to the example (centroid 90 60 and loudness -30 -50) I would get:
loudness > -30 = 1
loudness < -50 = 0
centroid > 90 = 1
centroid < 600 = 0
Which would get turned into a single point dataset with 1 0 1 0, which would then satisfy the query.
The glaring problem I see here is that would only be true if those transitions happened at the same exact time, and wouldn’t “persist”.
///////////////////////////////////////////////////////////////////////////////////////////////////
So yeah, a bit of a brain fuck, trying to think about time, in a relatively time-less system.
Any thoughts on how to go about this?
