So for a few years now I’ve been using a combination of fluid.ampfeature~ in combination with a gen~ subpatch that is the thresholding component of fluid.ampslice~ as I always wanted the note offsets as well as the onsets (in a gate signal at least). Something like this:
(this is an abridged version of dk.onset~ from Data Knot)
I have found this to work well, musically-speaking, as the gate duration here adds some musical variation and emphasis that can be used to trigger ADSRs/etc… from the same onset detection algorithm. In general the “note duration” here (the time between onset and offset) is pretty tiny given how all the envelope followers work. So works especially well for short/percussive sounds, but for long tones, it is all but useless. Or rather, “it doesn’t work” with long signals.
So I got to wondering what an optimized version of an “offset detection” algorithm would look like?
So as a thought experiment, here are two signals, with what I would expect in terms of onset/offsets:
Given what I know about fluid.ampslice~, this seems impossible given the current approach as the envelopes are “symmetrical”. You can obviously have different up/down times for both the fast and slow envelopes, but whatever you choose will be what is used for the gate going high, and then again for the gate going low.
What I’m, naively, picturing is something that would use the existing fluid.ampfeature~-type thing to detect note onsets, but once the gate goes high, a different algorithm and/or logic would take over which would be looking at a longer window, different criteria etc… Can even be frequency-based (or even novelty?) at that point, though that starts getting a bit spicy.
Ideally the onset part of the algorithm can always interrupt the offset such that it can still be as responsive as is needed, but with the option to have more descriptive offsets where possible.
So before going down this rabbit hole further, is there a best practice for this kind of thing, specifically in a realtime context, with a time-based onset component? I would think that this sort of thing, offline, isn’t a big deal, or even using a frequency/window-based approach would make comparing overlapping windows and their differences much easier.
AND / OR
Any suggestions for what would make for a good combination or approach given the available algorithms?