I’ll do some testing once the object is updated to see how fast I can get it, but I’ve never been able to get the Max (or fluid.) version to work on fast drum hits.
My concern in mentioning that, same goes for the other thread, is that it wouldn’t be possible to code in the fluid. environment at all if the optimizations occurred within the algorithm (because the object/algorithm is coded as a black box), but in looking at my older post on the topic, the ‘roll detection’ appears to happen after the onset detection but before the spectral analysis:
Specifically this diagram:
My original thoughts in the thread about specificity are that sometimes it will not be possible to “code it ourselves” if the algorithms don’t allow for procedural and content-aware variations (within the algorithm).
//////////////////////////////////////////////////////////////////////////////////////////////////
For example, to brainstorm, fluid.ampslice~ could output something saying that the @minslicelength is in effect, but another onset(s) has arrived, allowing for a forked treatment (different thresholds and whatnot) of what has arrived in that time since something within a roll, or very fast hits, may require different thresholding than an attack in open air.
Granted, some of that can happen outside the object, by just setting the @minslicelength to zero and then having a manual process fork sending but it can get real sloppy real quick, as well as involving double processing potentially.
That’s just a quick brainstorm, but it doesn’t seem crazy to me to having a lockout just be a conditional state, rather than an absolute one.
edit:
So in thinking about that last example, I could have two separate fluid.ampslice~ running, and then do some external logic to compute a lockout flag (i.e. if onsets arrive >50ms use the output from the “slow” fluid.ampslice~, and if they arrive <50ms use the output from the “fast” fluid.ampslice~, but then it’s a lot of wasted cpu on the “fast” one, as well as the risk of missing onsets between the transitions because even the “fast” one would likely have to have a small lockout, which could happen during a transition).
So if as part of the future “curves” output (or whatever it would be (signal rate or Max? (timing/synchronicity?))), if there could be a flag that says whether the lockout for @minslicelength is active, and if so, then a feedback loop can be programmed which sets different/new @thresh values (if it is tight/accurate enough to do so). I don’t know how the internal envelope followers respond to dynamically changed thresholds (do they zero out/reset, do they just morph, etc…), so that may not even be viable.
But again, this is something that is not really possible (to easily) “code oneself”.