# Consistency in @debounce units (and elsehwere)

**URL:** <https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215>\
**Category:** Bug Reports and Issues\
**Created:** [June 2, 2019, 8:29am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215 "2019-06-02T08:29:16Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [June 2, 2019, 8:29am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/1 "2019-06-02T08:29:16Z")

</div>

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](https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205/2?u=rodrigo.constanzo) 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…).

---

<div class="post-metadata">

**Author:** ![tremblap](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tremblap/32/5_2.png) [@tremblap](https://discourse.flucoma.org/u/tremblap)\
**Post date:** [June 2, 2019, 8:48am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/2 "2019-06-02T08:48:45Z")

</div>

> [@rodrigo.constanzo](#):
>
> 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?

there is, as you can imagine 🙂 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.

---

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [June 2, 2019, 8:58am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/3 "2019-06-02T08:58:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [June 4, 2019, 9:21am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/4 "2019-06-04T09:21:38Z")

</div>

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`](https://discourse.flucoma.org/t/something-wrong-with-function-6-of-fluid-onsetslice/216/5) since I could have sworn it was `@algorithm 6` I was referring to).

---

<div class="post-metadata">

**Author:** ![tremblap](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tremblap/32/5_2.png) [@tremblap](https://discourse.flucoma.org/u/tremblap)\
**Post date:** [June 4, 2019, 10:26am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/5 "2019-06-04T10:26:40Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [June 4, 2019, 10:28am UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/6 "2019-06-04T10:28:12Z")

</div>

I imagine @groma will have a thought too

---

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [June 4, 2019, 1:24pm UTC](https://discourse.flucoma.org/t/consistency-in-debounce-units-and-elsehwere/215/7 "2019-06-04T13:24:08Z")

</div>

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.