Here’s a patch I made comparing a few of the different real-time options for transient extraction. I’ve tweaked most of the parameters to get something useful/musical with the given source input (linked below), but it’s by no means perfect.
Low latency hpss (some artifacts, but latency was highest priority)
Better sounding hpss with less artifacts
“Cleaner” transiets but still some artifacts (hard to tune this one
Using a “fake” enveloped approach
Some thoughts:
Would be great to work out the ‘lowest functional latency’ settings for material like this.
What is the (perceptual) difference between a “transient” (from fluid.transients~) vs an “onset” (from fluid.hpss~)?
Does a ducker/crossfader do a convincing job of “taking it”? (fluid.transientslice~)
HPSS is a harmonic / percussive separator. Percussive does not equal onset (or perhaps more clearly onset does not equal percussive). In choral music a note onset can be non-percussive.
Cool, I’ve edited the original post to take those changes into account. Brings the latency of the “enveloped” version down to 13ms, which is nice. Still just plain time-domain slicing though.
On listening to this a week later, I think I actually like @a.harker’s “transient” a bit more, in that it could make for better processing, but with sounds this short, it’s a subtle difference.
To my ears, I think the “transient” is probably somewhere between the HPSS and Alex’s solution. (like if Alex’s could be a touch longer, temporally).
I have no idea what it’s doing now, but is a fixed duration of what is (mathematically?) considered a “transient”, or is it when a signal peak drops below a certain level? (as in, varying in duration depending on the length of the audio transient)
Maybe there can be a secondary duration that is calculated to give an ‘onset’, which goes through a secondary thresholding (which can to no longer than the window time).
Then perhaps having a flag for what you are requesting: transient or transient+onset as what is separated.
Thanks for all these thoughts. You are confirming some knowledge gap and ambiguities here which are helpful. For instance, transient and onset are related, but they have different definitions.@groma@weefuzzy and I, and @a.harker, will have to agree on a working definition of each and then produce a document on the KE website for that.
The idea of having transient then duration is what I’m interested in. Onset can be non-transient based (for instance, a tuba note has no transient most of the times) but has an onset.
Yeah totally, though I guess I’m still unclear as to how a “transient” is defined (fixed duration, or based on a thresh of some kind).
Having some clarity and definitions would be most useful too, and I would think also be useful to clump together into a single kind of decomposition. (So one doesn’t have to pick an object for transients, and another for onsets, as there could very well be messy overlap there)
It’s still kind of tricky to find some useful settings here, and it almost sounds like debounced isn’t actually fixed for the fluid.transients~ (listen to the perc part while playing brushes.aif, it sounds like crosstalk/AM).
Even with the settings really fine tuned, to my ear, a “transient” is something between the output of hpss (too long and sloppy), and transients (way too short and blippy).
The transients here will be short and blippy. That is the nature of the algorithm and was a question we asked within the project “what is a transient” - I would probably take something longer as a musical item, but PA requested the blippy stuff, and that is what the declikcing is designed for.
The last code update was from Gerard in December and looks like a debounce fix, but I had a memory of revisiting this more recently.
1 - the transients sound like what I’d expect form the algorithm (based on listening, rather than more technical testing).
2 - I don’t think that the debounce can go over the Block size. That might be something to improve in the interface or to revisit in terms of the design.
Hmm, that seems quite short then if that’s the case (and confusing in terms of the helpfile).
In the case of the patch I posted the block size is 512, so the AM I’m (think I’m) hearing would be faster than that anyways. It sounds to me like my memory of when there was no debounce at all and it was just crunching on/off all the time.
Yeah I’m more in line with you if that’s the case. The bit that’s not ideal really is that hpss is way too long, and in fact sounds like a filter, rather than having a temporal impact on slices, and then the other option is the transients~, which I can see having a use, but it is super extreme for every day use.
I guess the first toolbox is already at “feature freeze”, but having some kind of control/parameter for how transient vs onset the extracted transients arewould be "flexible and powerful"™. (edit: made a feature request thread)
You did not implement it right though: