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

round BPM values from analyzer #2668

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Commits on Apr 15, 2020

  1. Prefer round BPM numbers

    If the analyzed bpm is not a round number within a reasonable margin, check
    if 2/3, 3/2 or twice the bpm is a round number within reasonable range.
    
    This fixes most cases where the bpm is reported as 96.666 or similar, highly
    unlikely numbers.
    
    cleanup whitespaces
    poelzi committed Apr 15, 2020
    Configuration menu
    Copy the full SHA
    0c46cae View commit details
    Browse the repository at this point in the history
  2. Round only to one decimal place if there is no information loss

    Before commit ae392c9 it was very
    easy to spot wrong BPM value by the fact they where odd looking.
    The new behaviour rounded 100.012232 to 100.0 so there was no way
    to see if a number is odd in the first place without hovering
    or editing.
    
    Now the track list will use 2 decimal points if there is a rounding
    error introduced, making it easy to spot odd or wrong BPMs.
    poelzi committed Apr 15, 2020
    Configuration menu
    Copy the full SHA
    ad0230b View commit details
    Browse the repository at this point in the history
  3. Round bpm on scaling operations if the error is marginal.

    If the error of rounding is very small, it makes sense to round
    the scaling bpm errors, which is a common error from the bpm analysis.
    poelzi committed Apr 15, 2020
    Configuration menu
    Copy the full SHA
    174f910 View commit details
    Browse the repository at this point in the history