round BPMs in hierarchical sorting

[mixxxbot]

Reported by: Be-ing
Date: 2015-08-04T15:25:52Z
Status: Confirmed
Importance: Undecided
Launchpad Issue: lp1481396

---

It would be nice if hierarchical sorting treated BPMs with decimal points as having the same value as the nearest integer. If I sort by BPM then key, the key sorting order restarts when the BPM value changes by even .01, which is practically the same BPM.

[mixxxbot]

Commented by: daschuer
Date: 2015-08-04T15:58:03Z

---

Why nearest integer? What is the why should 88.49 be sorted away from 88.51?

I understand the underlying use-case, because I had the issue as well.

But I think we need something more intelligent.

[mixxxbot]

Commented by: Be-ing
Date: 2015-08-04T16:07:48Z

---

The nearest integer might not be the best way of going about it. What about rounding to every 2 or 5 BPM for the purpose of hierarchical sorting?

[mixxxbot]

Commented by: kazakore
Date: 2018-09-24T18:27:14Z

---

I think anything other than integer value for this would be weird. I don't whether you round to the nearest integer (rounding by 0.5) or just ignore the decimal really makes a huge amount of difference either. In fact I'd lean more towards ignoring the decimal and always rounding down, as then the grouping matches the visual representation and it still performs the function of grouping tracks and removing the areas between BPM where things miss the additional hierarchical sorting orders.

[mixxxbot]

Commented by: uklotzde
Date: 2018-09-24T21:05:44Z

---

Please prefer rounding towards the nearest integer instead of simply cutting off decimals by applying a floor() function.

Nowadays most tracks are quantized on integer bpm values. Though due to post-processing, encoding, or rounding errors during analysis Mixxx sometimes detects slight variations, e.g. 127.99 or 128.01. I expect that these tracks are sorted into the 128 bpm slot.

Mathematically it doesn't matter if you use round(), floor(), or ceil(). But when developing software you always need to take the actual use case and the context into account.

[mxmilkiib]

Given the differing opinion on what to round/floor a BPM to when displaying/sorting in the BPM column, how about a menu to select a choice from in the Library Preferences?

[daschuer]

I don't think it is reasonable to have a static preferences option that disables sorting for BPM values in a certain visual range.

For my understanding the grouping is desired here for the special use case of finding compatible tracks in a key progression. For that case even a 120 and a 121 BMP track should be considered. The center value of the group depends on the desired target tempo.

Does that match your use case?

We already have such a feature. Maybe it is not accessable enough?

Can we turn it into an conditional grouping feature that not hides track from the list?