Definitely talking about the realtime one. The offline ones have Reaper, and the @leafcutterjohn (and future @jacob.hart) version, but this one is enigmatic.
So having the “raw” curves output will go a long way, and would just need the obvious things there (differential, the curve from each envelope follower etc…), as well as having a clear signal path and labelled topology.
But if we’re going “all out”, having an interactive thing would be very useful:
(not sure if the discourse auto-embed takes the starting time, but at 7:31 is what I’m mainly talking about)
Where you can set a base noise floor, as well as thresholds (as relative to the visual envelope following) in a meaningfully interactive way. You can also see the note onsets/offsets as they related to the incoming signal.
That would not only take the guesswork out of the current setup, but also let you arrive at more meaningful settings (given the incoming material type), as being able to see the curves is still abstracted from the results that the algorithm produces.
(this could also end up being really crazy if you incorporate the greedy/pre/post stuff it can do, so that would be great for getting into that too, but I’m mainly concerned with the vanilla implementation(ability))
//////////////////////////////////////////////////////////////////////////////////////////////////
Having parity with the Max version would be nice too, even if it ends up not being possible if you implement things that work “better” than the vanilla Max one (and have an easier system to find solidly working settings).
//////////////////////////////////////////////////////////////////////////////////////////////////
Lastly, this relates a bit to the discussion in this thread, but it would be great to have some kind of control over how the algorithm works in a “real-world” context, specifically as it relates to “rolls”.
Most of the reading I’ve done around onset detection algorithms tend to have a processing fork that deals with behavioral edge cases like “rolls”.
I can smell @tremblap’s “you can code it yourself” coming a mile away, but this seems like that kind of thing that is natively useful to an object that detects onsets (just like the greedy/pre/post stuff is possible if one “codes it oneself”, but it’s integral enough to be incorporated into the actual object).
I don’t know enough, dsp wise (although also in general!), to know what that would mean in context, but it’s something I was pushing up against in the vanilla Max version (in this thread).
Just a thought.