groovindj
The latest update is hiding BPM variations from the user.
In the previous version, BPM variations were visible - both in the BPM Editor after fluid analysis and as changes to the BPM readout on the decks (jogwheels).
Now they're gone. After analysis the blue "variations" line is just straight (unless the change is large), there are no regular BPM changes displayed on the lower waveform, and when loaded to a deck, variations are no longer shown as changes in the BPM readout.
IMO this makes it almost impossible for the user to know what the BPM is actually doing. It also makes it hard to know whether the tempo is being stabilized or not.
Yes we have the small tilde and padlock symbols, but there are far more skins being used that do not have these yet - and may never be updated to include them.
In the previous version, BPM variations were visible - both in the BPM Editor after fluid analysis and as changes to the BPM readout on the decks (jogwheels).
Now they're gone. After analysis the blue "variations" line is just straight (unless the change is large), there are no regular BPM changes displayed on the lower waveform, and when loaded to a deck, variations are no longer shown as changes in the BPM readout.
IMO this makes it almost impossible for the user to know what the BPM is actually doing. It also makes it hard to know whether the tempo is being stabilized or not.
Yes we have the small tilde and padlock symbols, but there are far more skins being used that do not have these yet - and may never be updated to include them.
Posted Wed 04 Mar 26 @ 2:07 pm
Adion
Depends what you consider the 'BPM'.
If a track is averaging 125 BPM, but the drummer hits a single kick a little bit early, would you really consider the beats before that event at 130BPM, and the beats after that event at 120BPM?
And what is even the use of this information?
If you want to pick a new song that is in line with the tempo, seeing 125 BPM is more useful, if you want to manually beatmatch, seeing 125 BPM is more useful.
If a track is averaging 125 BPM, but the drummer hits a single kick a little bit early, would you really consider the beats before that event at 130BPM, and the beats after that event at 120BPM?
And what is even the use of this information?
If you want to pick a new song that is in line with the tempo, seeing 125 BPM is more useful, if you want to manually beatmatch, seeing 125 BPM is more useful.
Posted Thu 05 Mar 26 @ 1:26 pm
groovindj
I consider the BPM to be just that - the beats per minute - not the average over the entire track (which is what we had before fluid grids), and not a constant figure that doesn't change even when the tempo drifts.
Please don't take that literally though. I don't want the BPM to only be updated every 60 seconds!
The previous build correctly showed small BPM variations live while the track played, showing the DJ exactly what was happening. Now the only way to see if the tempo drifts is the small tilde symbol - which as stated is not present on the vast majority of existing skins. The tilde does not show exactly what the current BPM is, or whether it has increased or decreased.
On the other hand Algoriddim's djay Pro shows a live BPM, including all increases/decreases.
Even prior to fluid grids, there have been many posts here from people requesting a live BPM readout rather than an average - going back many years.
James Hamilton (Record Mirror) used to list BPMs from 1979 onwards, meticulously timed throughout each track, enabling DJs to mix at any point.
There's not been much comment on this change from other users yet, but I suspect I'm not alone in wanting to have visible feedback of tempo variations.
Please don't take that literally though. I don't want the BPM to only be updated every 60 seconds!
The previous build correctly showed small BPM variations live while the track played, showing the DJ exactly what was happening. Now the only way to see if the tempo drifts is the small tilde symbol - which as stated is not present on the vast majority of existing skins. The tilde does not show exactly what the current BPM is, or whether it has increased or decreased.
On the other hand Algoriddim's djay Pro shows a live BPM, including all increases/decreases.
Even prior to fluid grids, there have been many posts here from people requesting a live BPM readout rather than an average - going back many years.
James Hamilton (Record Mirror) used to list BPMs from 1979 onwards, meticulously timed throughout each track, enabling DJs to mix at any point.
There's not been much comment on this change from other users yet, but I suspect I'm not alone in wanting to have visible feedback of tempo variations.
Posted Thu 05 Mar 26 @ 1:49 pm
Adion
Actually djay also doesn't show every single change.
Edit: The value shown is also not the average over the entire track, but the local average over which the bpm only has small phase changes, but no major tempo changes
Edit: The value shown is also not the average over the entire track, but the local average over which the bpm only has small phase changes, but no major tempo changes
Posted Thu 05 Mar 26 @ 2:02 pm
groovindj
It does show changes though, as did VDJ before the recent update. The previous analysis put red anchors down thoroughout the track, each one having a BPM value to it, which made the jogwheel BPM readout change so we could see what was happening.
Now there is no way to see what the BPM is on a certain section, either in the editor or when the track is on a deck. If I load a track that drifts, when I click through the overview on the deck, the BPM displayed on the jogwheel doesn't change. It doesn't change when playing the track either (unless it's a large shift).
I'm just saying that I'd prefer to see (via the BPM display) that a track drifts, not just from a tilde.
Now there is no way to see what the BPM is on a certain section, either in the editor or when the track is on a deck. If I load a track that drifts, when I click through the overview on the deck, the BPM displayed on the jogwheel doesn't change. It doesn't change when playing the track either (unless it's a large shift).
I'm just saying that I'd prefer to see (via the BPM display) that a track drifts, not just from a tilde.
Posted Thu 05 Mar 26 @ 2:13 pm
DJ VinylTouch
Fully agree with this too. If I don't want to see the drift, I would enable stabilization (the readout should always tell the truth).
Posted Thu 05 Mar 26 @ 2:38 pm
groovindj
According to the current analysis, Big Blow (Manu Dibango) has a few 119 bars at the start, then sits at exactly 123 for the next six minutes, never varying - when what's actually happening is this:
Posted Thu 05 Mar 26 @ 3:27 pm