Transient separation

Is there a downside to configuring transientslice~ to have the biggest possible order value with the limitation being the CPU? From the reference, it seems it has no effect on temporal resolution but gives more clarity in the low end, which is probably good for me.

It seems too good to be true in a way, and I’d like to know if there is any caveats of this parameter that are not explained in the docs.

@a.harker knows the algo inside out, I think the CPU cost of the model is much higher with large order… which is in itself a trade off :wink:

CPU usage will go up with order and if the block size increases. The order controls the number of poles, which is related to spectral resolution, but in a manner different to FFT bins (as poles are mobile in frequency space, whereas bins are not.

Does that help?

I guess if CPU is not an issue (non-realtime or whatever), is “going as big as you can” a solid move?

Only up to a point, I think.

My understanding of the algo is still pretty touchy-feely, but to the extent that what’s its trying to do is build a model that ‘explains’ the samples in the analysis window (plus the padding), the blocksize and the order co-determine the sort of time-scales it can make sense of (hence the lower-frequency behaviour). Presumably, beyond a certain range, the returns (in terms of perceived accuracy) won’t justify the quite substantial extra CPU cost of ramping these parameters up.