for DJs show BPM tenth hundredth resolution [#3032]

[richjoh-]

I'm a DJ, I use MM to organize my music. I want MM to store and display the BPM down to the tenths or hundredth of a BPM.

It appears to me that MM rounds decimal digits to integers in the BPM field, or at least thats what is displayed. My DJ software, or any DJ software for that matter needs to use BPM to the 10ths of Beat, example 77.4 entered using MM and it shows 77 for BPM. But get this, MM doesn't always round the number up either. I enter 77.7, MM may show 78 or 77 (I've not had the time to go through this in detail).

Even better would be a BPM analyzer that could do a quick analysis and determine the BPM by analyzing a section of the song. I keep telling these DJ software developer they don't need to analyzer the entire song (taking up to a minute or more hogging the cpu) to find the BPM. If this built in BPM analyzer is going to be inaccurate though, please don't bother. DJ software must use hundreths (example BPM 77.46) for accurate beat mixing. I tried the BPM tapper script plugin and it was just too inaccurate for my craft.

[Orbi]

+1

I would like to see a BPM analyzer as well. richjoh has a very specific purpose for it, I don't need it to be that precise but it doesn't hurt.

[Lowlander]

Already requested: http://www.ventismedia.com/mantis/view.php?id=3032 & http://www.ventismedia.com/mantis/view.php?id=8428

[Peke]

Along with http://www.ventismedia.com/mantis/view.php?id=7181 regarding Harmonics Mixing technique.
and http://www.ventismedia.com/mantis/view.php?id=5924 regarding CUE Points and crossfading automation.

MM4.1 should improve MM usability for DJs

[richjoh]

Lowlander,
Your Mantis link has it 100% correct, an INTEGER in the BPM field for the ID3 BPM spec is NOT the defacto standard. Using DECIMALS in BPM is the defacto. DJ do things like looping, beat mixing, cutting, scratching and sequencing to name a few all while not missing a beat, an accurate BPM is needed. It appear MM management is slow to respond. The original Mantis posting is from 2007-05. Get with it, it like watching a clock and not having a big hand to tell you the minutes. If its 5 O'clock you have 1hr of descrepancy before you know it 6 O'clock. Keeping with same scenario DJ software needs to know the msec of BPM.

What are the chances of this being implemented? Its a part of the TAG information. Any standard will never keep up with changing technology and trends. It would have be rewritten yearly.

I'm using version 3.2 now when is 4.1 release date. It should go in version 3.3.

[djmt99]

And from yet another DJ: Add color-coding (it's been discussed, I know) and for gawd sakes, a Mac version!

FWIW, I don't think the decimal on the BPM field isn't that critical. Most of the DJ pool tracks are tagged without decimal, and unless you're using some form of auto-mix, any decent beat-mixing DJ can nail a mix without looking at waveforms or BPM's.

[Lowlander]

That makes no sense, MediaMonkey 4 is already close to release. Anyway there are many requests and their isn't enough time to add them all, so their importance needs to be weighed as to what will be honored and what will have to wait. There are plenty of requests that are much older than the BPM request. In the end we all have requests that we'd really like to have taken care off, but will have to wait.

[DrKNo]

So as I am seeing, this request is from five years ago with the last activity being half a year ago. Could I please get an update on what the standing ist? I am unable to use MediaMonkey on my Main Computer because of this bug.

One might agree to djmt99, but ONLY under the circumstance that one is simply not using autoloops or any other bpm based feature (Iam NOT talking auto pitch). That's fine for anyone that doesn't, but most djs that work with more than two decks or are doing more than just mixing and the occasional overdub will probably use autoloops or other bpm dependent features (filters, effects, midi trigger...). If just one out of 100 tracks gets his bpm cut off - that track will possibly cause a trainwreck. The statement that "any decent beat-mixing DJ can nail a mix without looking at waveforms or BPM's." is true, but also irrelevant in the same way that the statement "Any decent music collector can still use vinyl to listen to music, no one needs MediaMonkey for that" is irrelevant. Software like Traktor will simply not work correctly with incorrect values.

To be more specific:
1) Any DJ using Beat grid based Software like Traktor, Serato Itch and many other smaller ones will be unable to use MM
2) DJS that use non Grid Based tools like SSL (like I do) will have problems as soon as they want to use any features that make Digital DJing interesting (apart from not having to carry your record collection around anymore).

Mediamonkey is passively destroying information here with no way to control it. I have paid for two lifteime pro licenses and i cannot currently use the software. I am asking you to *please* make this a priority and / or a time horizon for when this might be fixed. I have a Masters Degree in Informatics in my daytime profession and I will happily go out of my way to help solve this (Though this offer is probably futile).

I am looking forward to your reply.

[richjoh]

All that DrKNo mentioned is 100% correct. It is now 8 months since his post above and now 6 years and counting.

The way MM currently works is erroneous, the BPM field is populated with a decimal and MM reports a rounded integer. At the very minimal, MM should report exactly what is (decimal or not) populated in the BPM field. Second, MM must SAVE decimal or integer in the BPM when the field is populated or changed.

Currently, if the BPM is changed to decimal number, MM rounds the number to an integer and save BPM as integer. (This is not what the user enters, the user is not notified, no bells, indicators or reject notification). I'm quite certain this is a very simple change that would have minimal side effects. MY DJ SOFTWARE ALREADY DOES THIS, saves the BPM in decimal.

I'm no longer requesting a bpm analyzer, just fixed the BPM field right now.