Change BPM: fraction bpm-change result preview

[mixxxbot]

Reported by: mxmilkiib
Date: 2020-09-24T22:43:00Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1897186
Tags: bpm, usability

---

So far, it appears to me that if Mixxx gets the tempo incorrect, it gets it incorrect at some fraction of the actual bpm.

This is why the 'Change BPM' submenu has entries to adjust the number by some fraction.

But I would suggest that many cannot think in these terms and could compound the problem, something stressful whilst trying to mix.

My suggestion would be an option in the 'Change BPM' submenu for 'Tap to detect fraction change' or something; because whilst a tap tempo might (probably won't imho) give the correct bpm, it will (most likely) give a bpm near one of the resultant bpms from the fraction change options that are available, thus alleviating that choice from the user.

[mixxxbot]

Commented by: ronso0
Date: 2020-09-26T11:03:08Z

---

Are you actually askinf for a 'Round BPM' action button?

related: #10010 "increase BPM tap filter length"

[mixxxbot]

Commented by: mxmilkiib
Date: 2020-09-26T15:04:40Z

---

Not here, though I did recently make a specific UI suggestion for "Round scanned BPM values" #9464

I'm more meaning that, if I want to play a track, but the bpm is wrong, (and assuming Mixxx bpm detection is only off by a ratio) I think there is a middle UX possibility between a) having to work my brain about what bpm change ratio I should be applying (and maybe how to reverse/reset/fix if I get it wrong) and b) hoping that I can precisely enough tap out a "bpm" that'll get me to the middle/end of the track.

A sort of relate-taps-algo-bpm-with-feature-detection-algo-detected-bpm-to-fix-bpm thing.

[mixxxbot]

Commented by: ronso0
Date: 2020-09-28T13:34:25Z

---

okay, now I understand.

I see two ways to fix the situation:
A) in the track context menu > BPM submenu, have a BPM conversion preview next to the conversion factors like 2/3 (174 BPM)
B) add a 'Tap correction' action to the track context menu > BPM submenu that opens a dialog that

• allows to tap
• multiplies BPM with all available fractions [2/3, 3/2, 4/5, 5/4]
• picks the one that comes closest to the tapped BPM)

( detected BPM )
[ TAP button ]
( tapped BPM )
( assumed target BPM )
[ Apply ]

I think we should go with the BPM preview ;)
Imo the fractions we have available produce BPMs that are easy enough to distinguish, right?

From the library table, this would work for single tracks only though.

[mixxxbot]

Commented by: mxmilkiib
Date: 2020-09-30T14:10:19Z

---

> I think we should go with the BPM preview ;)

Haha, you make a very good point :)

Imo the fractions we have available produce BPMs that are easy enough to distinguish, right?

Sure, it appears a fair balance for humans.

[mixxxbot]

Commented by: mxmilkiib
Date: 2020-10-03T01:50:23Z

---

Having thought about it and tried some more, the next logical question after "what if you don't understand the fraction?" is "what if you don't understand the bpm?", as in, the user doesn't know what that bpm number "means". So, to channel some Bret Victor, would it be too much to have the lines in the change-previews submenu finish visually with a dot that flashes at that bpm?

[mixxxbot]

Commented by: daschuer
Date: 2020-10-03T22:29:07Z

---

How about just add a checkbox
[ ] pick closest fraction when tapping.

[mixxxbot]

Commented by: ronso0
Date: 2020-10-06T13:44:58Z

---

"what if you don't understand the bpm?"

Is it not sufficient to see/hear the relation of vertical strokes on the waveform to peaks in the waveform shape?
If a user doesn't know what the BPM number means why would s/he want to change it?
Whenever I introduce formerly non-DJs to Mixxx and they don't know about BPM, they usually also don't care about it and don't touch the pitch slider, let alone Sync or Quantize controls.

"would it be too much to have the lines in the change-previews submenu finish visually with a dot that flashes at that bpm?"
That would make sense IF the respective deck is playing, but IMO it should then also be aligned with the 'real' downbeats, which probably hard to achieve if Mixxx detected the wrong BPM in the first place.

Let's go with the BPM number preview first.

[mxmilkiib]

My original proposal and answers on this one were a bit wordy and confusing.

So, the proposal; add the calculated BPM as text to the end of each option in submenu.

The Search Related Tracks submenu already has dynamic content depending on the selected track.

E.g. for a 93.3 BPM track, the submenu would show;

• Double (186.6 BPM)
• Half (46.65 BPM)
• 2/3 (62.2 BPM)
• 3/4 (69.98 BPM)
• 4/3 (124.4 BPM)
• 3/2 (140 BPM)

which makes things a lot clearer.

Or maybe as the same format as the Search Related ones I guess;

• Double | 186.6 BPM
• Half | 46.65 BPM
• 2/3 | 62.2 BPM
• 3/4 | 69.98 BPM
• 4/3 | 124.4 BPM
• 3/2 | 140 BPM

See also: #12579

[mxmilkiib]

Thank you for adding the resultant tempos to the Adjust BPM menu, that is and will be a great help! And also for resolving #12579 at the same time!

From a quick scan, there were three proposals, rephrased/summed up here;

• A "snap the bpm to the fraction of incorrect detected bpm that is nearest to the tapped tempo" thing (the original idea)
• A "preview the resultant tempo" (what the issue pivoted to and what the title was changed to refer to)
• A "visually flash a circle character in the menu next to the the possible tempos at the rate of that tempo" (a more literal visual style of previewing the resultant bpms, because if I see 140/160/170 it's obvious which one, but if I see something for each fraction that isn't clearly 'to an integer' I still might not be able to imagine which to pick - this is aimed at people who are really bad at music)

Maybe the other two should be spilt out just to keep 'one issue to one feature'?

My 2p regarding the worth of each;

I understand better now the worry about the probable complexity 'problem' with "flashing preview in the menu would be better if the user is actually playing the track" and "the preview should start flashing in relation to the track start or primary cue" (I think that's a more logical approach than "relating it to the true downbeats", which is a paradox!)

Also, if the track bpm is going to be snapped to the "fraction of the detected that it's nearest the tapping" (which could be initiated by holding down ctrl when clicking"TAP"(?)), it's not intuitively obvious that the result is securely correct; if comprehending the waveform and beatgrid of the new tempo is still hard for some folk/cases, a flash of the new tempo is the method I think would round that off.

Adding a(n optional) flash of the tempo to skins is #5454/#5852/#12128, so my overall take is that that issue/feature should be the priority; personally I think it wins in terms of usefulness, it's simpler than the other two here.

P.S. I just added another BPM-alteration related FR issue, #12774