Fluid.transients~ erratic/random behavior

[rodrigo.constanzo]

@weefuzzy

For batch processing, if it’s truly offline, you have the luxury of being able to use some larger blocksizes and orders, which might help: if those clanks are all around 2000 samples (which is too big a blocksize for RT), then this might be a useful starting point for the blocksize. (use blocking 0 !)

That was my initial thinking, and @a.harker suggested some nice and chunky settings back at the 3rd plenary when I was first messing around with this idea. With those (particular) settings I got the “long and mushy” transients where there’d be a cluster of clicks, a gap, then some more clicks (on a small time scale, but still kind of KRRSH rather than CLICK).

@weefuzzy

Doesn’t solve your batch problem though. In a way, you’d kind of like to train the model across the batch and use that as a basis for detection (disclaimer: I might be talking out of my behind here).

I guess where I’m going with this, it doesn’t so much matter what the extracted transient is, since it will eventually get stitched together into a franken-sound. Sizing variabilities complicate that, but one problem at a time I suppose.

@weefuzzy

Yeah, it’s a tricky beast. I think there’s still hope of revisiting this algorithm in the futrue to try and understand its mysteries a bit better, and to complement it with another transient model as well (with a less click-centric notion of transient-ness: this is a declicking algorithm, after all!)

Definitely like the sound of that. As I’ve mentioned (probably oodles of times!) I think of a transient as something longer and identifiable, I guess closer to an “attack” or “hit”, but there’s definitely some usefulness to a short transient (as it’s presently pseudo-defined). I just haven’t gotten somewhere with the algorithm that satisfies either use(ful case).