round BPMs in hierarchical sorting

[Be]

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.

[Daniel Schürmann (daschuer)]

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.

[Be (be.ing)]

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?

[Dale (dj-kaza)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8190