Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search: add special BPM filters #12072

Merged
merged 18 commits into from
May 8, 2024

Conversation

ronso0
Copy link
Member

@ronso0 ronso0 commented Oct 7, 2023

rework of #12070
Closes #8191

This adds BpmFilterNode which allows the following special filtering:

  • ~bpm:N finds N +- n%
    n is % of the current rate slider range, can be configured in Pref > Library, default is 75%
  • bpm:N finds N¹ as well as N/2 and N*2 (in case N is odd N/2 is replaced with a range of prev - next integer, considering electronic music with mostly integer BPM)
    can be toggled in Pref > Library, default ON

¹N is turned into a range to cover the rounded values (in the tracks table or BPM widgets).
For example 102.5 becomes [102.45 - 102.55]

Btw, this works beautifully with the new OR operator: ~bpm:80 | ~bpm:160 : )

Results:

  • ~bpm:100: 94-106 NEW
  • bpm:125.2: [125.15 - 125.25] and [250 - 251] and [52 - 53] NEW
  • -bpm:100: anything except exactly 100.0
  • bpm:=100: 125.15 - 125.25

Preferences > Library
I re-grouped the options a bit, though we may discuss details like Metadata /Playlist title and the search note label

  • moved Misc options to Metadata & Track Table groups
  • added the Search group
    • fuzzy range selector (percentage of pitch slider)

library-search-options_

TODO

  • adjust NumericFilterTests to use something else than bpm
  • add BpmFilterNode tests
  • adjust 'fuzzy range' in Preferences > Library > Search
  • use fuzzy range also for 'Search related tracks' > BPM?
  • half/double search can be overriden with = operator (we just need to document it)

Manual

@ronso0 ronso0 changed the title Search: add special filters Search: add special BPM filters Oct 7, 2023
@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch 2 times, most recently from 29fcc79 to 8ecff43 Compare October 8, 2023 12:40
@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch 4 times, most recently from fcd122a to 685b1a2 Compare October 9, 2023 08:29
@ronso0
Copy link
Member Author

ronso0 commented Oct 10, 2023

This works as intended now.

We may discuss the default behaviour and the fuzzy options:

  • adjust 'fuzzy range'?
    • dynamically: full or part of pitch slider range?
    • in Preferences > Library > Search?
      • % range spinbox?
      • % range spinbox clamped to current pitch slider range?
      • also apply range to 'Search related tracks' > BPM?
  • toggle half/double search with checkbox in Preferences > Library > Search ?

@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch from 685b1a2 to bb71d01 Compare October 11, 2023 22:08
@github-actions github-actions bot added the ui label Oct 11, 2023
@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch 6 times, most recently from cd3be83 to 37e85a4 Compare October 12, 2023 09:14
@ronso0
Copy link
Member Author

ronso0 commented Oct 12, 2023

This works beautifully now, please test. Manual PR coming soon.
This has grown way beyond what I had in mind initially (story of my life..) so I'll take a break now. No hurry with reviews and so on.

edit
now broken after rebasing onto main with #12063 😝
fixed

@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch 2 times, most recently from feb0518 to b2d1f25 Compare October 12, 2023 12:00
Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only looked at the first commit so far. The rest got too complicated too quickly for me. I think that we can merge without N/2 & N*2 as well as the configurable config option since those two changes incur the most complexity.

src/library/searchquery.cpp Outdated Show resolved Hide resolved
src/library/searchquery.cpp Outdated Show resolved Hide resolved
@ronso0
Copy link
Member Author

ronso0 commented Oct 12, 2023

I think that we can merge without N/2 & N*2

Half/was the reason I started this. Tbh I'm not motivated to split that up, first I'll wait for a real Mixxx session and test it in real life.

@Swiftb0y
Copy link
Member

I'm sorry, I'm not able to review this further then right now.

@ronso0
Copy link
Member Author

ronso0 commented Oct 12, 2023

Never mind, didn't expect anyone soon. Thanks for taking a look.

@ronso0
Copy link
Member Author

ronso0 commented Oct 16, 2023

I've split this up into a bit, and I removed the half/double config option since that can be overwritten easily with the = operator. Hope this is a bit easier to review now (but don't feel pushed, I'm aware this has low prio atm).

@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch 2 times, most recently from e74b713 to db5357b Compare April 4, 2024 18:24
@ronso0
Copy link
Member Author

ronso0 commented Apr 4, 2024

Done.
I'm sorry I had to force-push, I removed the fixup locally.

New DEBUG commit is ec9b557

@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch 2 times, most recently from ddb6d30 to be6f2b2 Compare April 4, 2024 19:22
@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch from be6f2b2 to 81be9dd Compare April 4, 2024 19:26
@ronso0 ronso0 force-pushed the search-bpm-fuzzy-halfdouble branch from 81be9dd to 0387942 Compare April 4, 2024 20:08

EXPECT_STREQ(
qPrintable(QString("(bpm >= 126.95 AND bpm < 128) OR "
"(bpm BETWEEN 63 AND 64) OR "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading this test, I think I got your point:

If we consider that we have a electronic music library with only *.0 BPMs the resulting 1/2 range of >= 63,5 and < 64.0
64 will produce no match. Even if matches they are only 1% off.

Is this your rational? Can you put that somewhere as comment?

EXPECT_STREQ(
qPrintable(QString("(bpm >= 126.95 AND bpm < 128) OR "
"(bpm BETWEEN 63 AND 64) OR "
"(bpm BETWEEN 253 AND 255)")),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

127 * 2 = 254
128 * 2 = 256
following the rational above we will find *.0 tracks with just bpm >= 254.95 AND bpm < 255
The current implementation lead to a not fully overlapping range:

original 
    127 [----[ 128 
x 2 (my expectation) 
    254 [--------[ 256
implementation
253 [--------] 255 
/2
126,5 [----] 127,5

Do we have a reason for this to match tracks, that would not be no longer match after editing the BPM /2?
I have probably not understand your goal.

@ronso0
Copy link
Member Author

ronso0 commented Apr 5, 2024

The scenario I worked with is that I have a 127 BPM track playing and I want tracks that match somehow (doubel / half) without having to think about rounding or tempo correction in advance.
For the halves and doubles I didn't have strict rules in mind as the tempo slider can compensate a larger BPM range (doubles), and halves should simply give a starting point.

I didn't think of doing /2 queries manually and thus didn't have the expectation that searching for BPM any of the found tracks would reveal certain tracks from the previous search.

I tried to keep the range setups simple and would love to get this merged soonish if the code looks good, then get feedback and refine certain match modes. I need to play with the current implementation myself, too.
If you have concrete proposals feel free to share commits.

@ywwg
Copy link
Member

ywwg commented Apr 5, 2024

@daschuer Is there specific behavior in the parser that you consider blocking your approval of this PR? Can you be specific about which query results you consider incorrect?

@daschuer
Copy link
Member

daschuer commented Apr 6, 2024

OK, I will give it a try.

@daschuer
Copy link
Member

daschuer commented Apr 6, 2024

You will find my proposal here: ronso0#67

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ready for merge after CI is done?

Thank you very much for this nice enhancement!

@ronso0
Copy link
Member Author

ronso0 commented Apr 6, 2024

Yup, IMO this is ready to go.

I'll update the manual ASAP.

@daschuer
Copy link
Member

daschuer commented Apr 7, 2024

After a final test I have discovered on remaining issue, that an even bpm value only reveals the single exact halve value.
128 reveals only "64.000000"

I have fixed it here:
ronso0#68


// Replace the locale's decimal separator with .
// This is handy if numbers are typed with the numpad.
argument.replace(',', '.');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should simply use QLocale().toDouble() below.
This might fail for 123.456,00 in case users have mixed locales (see #13051).
Currently it would fail if users type gb/us thousands separators 1,230.5

Both is acceptable IMO ;)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered your solution as quite smart, because we display the bpm with dot separator in the GUI and Library table but use a comma separator in editors. It is unlikely that one is using bpms above 999.

This issue is however only present in case the user has a locale with comma separators. In case of a dot separator local everything is consistent and the hack is probably not that smart. We should make it conditional then.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, ideally we'd have a regex using QLocale::groupSeparator() and QLocale::decimalPoint()

I'd prefer to merge this now to collect alpha/beat feedback and work on the regex in a follow-up.

@daschuer @ywwg Ready to roll?

@ywwg
Copy link
Member

ywwg commented May 1, 2024

sorry for the hold-up. lgtm!

@daschuer daschuer merged commit 75e94c5 into mixxxdj:main May 8, 2024
13 checks passed
@ronso0 ronso0 deleted the search-bpm-fuzzy-halfdouble branch May 8, 2024 08:44
cr7pt0gr4ph7 added a commit to cr7pt0gr4ph7/mixxx that referenced this pull request Aug 23, 2024
…kBox_enable_search_history_shortcuts

Fixes the copy-paste error introduced during a refactoring in commit
6e588ec (merged with PR mixxxdj#12072).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fuzzy BPM search
4 participants