Consistency in @debounce units (and elsehwere)

Is there a (really good) reason that the @debounce attribute in fluid.onsetslice~ and fluid.bufonsetslice~ are in units of hops rather than samples like everywhere else in the toolbox?

I imagine this may have to do with the underlying algorithm, but surely that can still be specified (ala fft settings) where the number has to be in multiples of the hop size, and then under the hood you do what you do elsewhere and round it to the nearest acceptable value? Or even better, just have it be a freely settable number but then say in the help file that because how the algorithm works it will only compute based on multiples of the hop size.

Similar to the issue discussed in the Descriptors comparison thread where the centroid is expressed in a “spectral bins as units”, having inputs (or outputs) that have no absolute meaning but rather depend on the settings of the object makes things very confusing, in terms of usability, but also readability of the patch.

If I have two of the slicing objects next to each other and one says @debounce 4410 and the other says @debounce 4, that’s very confusing, and for (seemingly) no benefit.

So my vote is to never have any input/output be a “unit” that changes based on the settings of the object and/or a non-standard unit (Hz, samples, etc…).

there is, as you can imagine :slight_smile: It is just that the values are not discreet. They will always be a multiple of the hopsize. So we thought that educating users was more important than ease based on lies.

consistency > usability > education

You only need to learn it once (or a few dozen times), but you use it far more than you learn it.

Lest you recall the “calculate your own latency time” debacle of `18!

On a more serious note, yes I can see that it would be useful to know that, but every time I see the object I think “that debounce time is waaay too low”, then remember it’s set in some non-standard, dynamically changeable units…

I think you should be able to set it to whatever you want (in samples!!), but it will only compute based on hop sizes.

Also just noticed that in fluid.pitch~ the attribute @algorithm is used, and in fluid.bufonsetslice~ the attribute is @function.

There’s probably a meaningful semantic difference between function and algorithm in a a computational context, but as a user it is confusing.

(in fact, I had originally misnamed and mislabelled the thread about @function 6 since I could have sworn it was @algorithm 6 I was referring to).

Nice catch. @weefuzzy will let me know which one is more sensible from his KE material.

I imagine @groma will have a thought too

For my tastes I think @algorithm makes more sense, since I would view the whole “thing” as a different algorithm, rather than a specific function inside a larger algorithm (which is probably why the distinction is here in the first place). As a user, code/algorithmic hierarchy isn’t high on my list of concerns.