Giving this a bump as I was reminded of this for the 3-way splitting stuff in the other thread..
It strikes me that if any other sample rate is chosen for that patch, it would break. Or rather, the initial ‘click’ I’m after IS 2ms. It isn’t 88 samples. 88 samples can mean anything from 2ms to 0.46ms in terms of real-world time. Now, I can work around that by using loadbang->mstosamps~->fluid.bufwhatever~, which gets messy really quick, and mitigates the massive usefulness of @attributes for all the objects.
Plus, some things get really really messy when you’re analyzing x amount of frames of time, and offsets of those frames of time, which are all dependent on sample rate.
So yeah, wanted to bump this as there was promising discussion of @units and/or leveraging the Max API to handle that without overly complicated the implementation of this.