Agreed - some of that stuff is what Algoriddim's other software (Neural Mix Pro) does, but it's sold separately & not integrated to their DJ software, and it's also Mac only.
It would be nice to have a "one stop shop" that can either align the grid to the track (a la Fluid Beatgrid) or align the track to the grid (a la Ableton Live warping).
It would be nice to have a "one stop shop" that can either align the grid to the track (a la Fluid Beatgrid) or align the track to the grid (a la Ableton Live warping).
Posted Wed 04 Dec 24 @ 1:02 pm
Yeah agreed some good suggestions there.
Posted Wed 04 Dec 24 @ 1:20 pm
I remember though, after Algoriddim defaulted to Fluid Beatgrid detection, some DJs posting on their forum in confusion because they could see the BPM readout changing, thinking the software was broken. :-)
They were so used to seeing just one BPM being shown, which didn't fluctuate, that they couldn't figure out why it was going up and down.
Looking forward to seeing the same type of posts here (assuming Atomix give us a live readout).
They were so used to seeing just one BPM being shown, which didn't fluctuate, that they couldn't figure out why it was going up and down.
Looking forward to seeing the same type of posts here (assuming Atomix give us a live readout).
Posted Wed 04 Dec 24 @ 1:35 pm
Well that happens now with manually gridded, vairable BPM songs.
I guess it could be helped with the ability to tune the window to consider a BPM for a change (anchor placement) - the larger the window, the less variance, but the less precise the grid would be in that area.
I also wonder if it's useful to provide visual indication of a track's BPM being variable, for example, the BPM field in the browser giving a range (~128-130 BPM) and maybe the Deck stating the BPM is variable.
I honestly don't see how they can avoid the readout fluctuation otherwise, but isn't that something that a DJ would like to see though?
If they did change keepBPMonAnalyzerUpdate to yes by default, it would avoid the new fluctuation behavior, but people would then complain about the feature not working or needing a manual rescan step to work (the problem with one software coming out with a feature, people think that's the way it's supposed to be, rather than if the behavior is reasonable). Per song BPM locking doesn't solve the problem, but at least it's a try.
I guess it could be helped with the ability to tune the window to consider a BPM for a change (anchor placement) - the larger the window, the less variance, but the less precise the grid would be in that area.
I also wonder if it's useful to provide visual indication of a track's BPM being variable, for example, the BPM field in the browser giving a range (~128-130 BPM) and maybe the Deck stating the BPM is variable.
I honestly don't see how they can avoid the readout fluctuation otherwise, but isn't that something that a DJ would like to see though?
If they did change keepBPMonAnalyzerUpdate to yes by default, it would avoid the new fluctuation behavior, but people would then complain about the feature not working or needing a manual rescan step to work (the problem with one software coming out with a feature, people think that's the way it's supposed to be, rather than if the behavior is reasonable). Per song BPM locking doesn't solve the problem, but at least it's a try.
Posted Wed 04 Dec 24 @ 2:02 pm
I'm not against live BPM readouts. Personally I'd rather see a truly live reading (rather than it switching when there's an anchor) but I'm old enough to remember hardware based live BPM counters when playing vinyl.
My guess is the people I mentioned have only been DJs since the software era, and are only used to seeing fixed BPMs. They don't realise that some tracks shift, because they don't see it.
Yes, the option to display (in the browser) either the low/high BPM variation figures, or to choose if you want to show start BPM, average BPM (maybe with a V next to it) etc. would be useful too.
My guess is the people I mentioned have only been DJs since the software era, and are only used to seeing fixed BPMs. They don't realise that some tracks shift, because they don't see it.
Yes, the option to display (in the browser) either the low/high BPM variation figures, or to choose if you want to show start BPM, average BPM (maybe with a V next to it) etc. would be useful too.
Posted Wed 04 Dec 24 @ 3:56 pm
Excellent suggestions and discussions here!
Meanwhile, over on the Algoriddim forums, the DJs are craving for a stems swap sampler like the VDJ one..!
https://community.algoriddim.com/t/stemswap-for-djay-pro/32327
Just like the old saying — the grass is always greener on the other side of the fence. 😁
Meanwhile, over on the Algoriddim forums, the DJs are craving for a stems swap sampler like the VDJ one..!
https://community.algoriddim.com/t/stemswap-for-djay-pro/32327
Just like the old saying — the grass is always greener on the other side of the fence. 😁
Posted Thu 05 Dec 24 @ 3:04 pm
Just thought I'd drop this here - a report of the problem that was brought up with fluid beatgrid syncing and tracks which have a dramatic change in BPM for a section (BPM reading is wrong and syncing produces bad sounding results):
https://community.algoriddim.com/t/improved-handling-of-bpm-fluctuations-that-sound-terrible-because-of-the-fluid-beat-grid/32454
I don't think this is even addressable by a project BPM in all cases - the right thing would be not to sync/mix at all at that point in time.
If considering implementing this feature, at the very least the docs for the feature would probably need to state this bad case.
Maybe syncing can be disabled if the BPM cannot be clearly detected/is too far out of range compared to a last # of bars?
https://community.algoriddim.com/t/improved-handling-of-bpm-fluctuations-that-sound-terrible-because-of-the-fluid-beat-grid/32454
I don't think this is even addressable by a project BPM in all cases - the right thing would be not to sync/mix at all at that point in time.
If considering implementing this feature, at the very least the docs for the feature would probably need to state this bad case.
Maybe syncing can be disabled if the BPM cannot be clearly detected/is too far out of range compared to a last # of bars?
Posted Mon 09 Dec 24 @ 11:06 pm
DJ VinylTouch wrote :
Just thought I'd drop this here - a report of the problem that was brought up with fluid beatgrid syncing and tracks which have a dramatic change in BPM for a section (BPM reading is wrong and syncing produces bad sounding results):
https://community.algoriddim.com/t/improved-handling-of-bpm-fluctuations-that-sound-terrible-because-of-the-fluid-beat-grid/32454
I don't think this is even addressable by a project BPM in all cases - the right thing would be not to sync/mix at all at that point in time.
If considering implementing this feature, at the very least the docs for the feature would probably need to state this bad case.
Maybe syncing can be disabled if the BPM cannot be clearly detected/is too far out of range compared to a last # of bars?
https://community.algoriddim.com/t/improved-handling-of-bpm-fluctuations-that-sound-terrible-because-of-the-fluid-beat-grid/32454
I don't think this is even addressable by a project BPM in all cases - the right thing would be not to sync/mix at all at that point in time.
If considering implementing this feature, at the very least the docs for the feature would probably need to state this bad case.
Maybe syncing can be disabled if the BPM cannot be clearly detected/is too far out of range compared to a last # of bars?
I can't even think of a reason why someone would need sync for that track 😝 But this just goes to show, no matter what people can NEVER truly depend on the software to make them sound good lmao!!
Posted Tue 10 Dec 24 @ 12:36 am
I agree with you but that's just us - everybody has their own use cases. The feature is really useful for automation of things based on the grid, but I wouldn't doubt that people are just leaving sync on and playing tracks (they don't think about beatmatching anymore).
This is also very interesting to me - in most circles I new of/participated in, VirtualDJ used to get a bad rap in the past for making this same kind of automation easy for DJs, but other software implement the similar things a few years later and gets praise instead, to the point that the automation is being requested instead of rejected.
This is also very interesting to me - in most circles I new of/participated in, VirtualDJ used to get a bad rap in the past for making this same kind of automation easy for DJs, but other software implement the similar things a few years later and gets praise instead, to the point that the automation is being requested instead of rejected.
Posted Tue 10 Dec 24 @ 1:24 am
I saw that post too, and my first thought was - why does it matter?
The DJ even states himself in the post that they're not typically points where DJs would mix in and out, therefore there's no need for sync to be on at that point.
I remember when Algoriddim first released FBG I found a track that confused it, but they updated it - which solved the problem. I think some of it is also probably down to people not knowing how to edit the FBG.
The DJ even states himself in the post that they're not typically points where DJs would mix in and out, therefore there's no need for sync to be on at that point.
I remember when Algoriddim first released FBG I found a track that confused it, but they updated it - which solved the problem. I think some of it is also probably down to people not knowing how to edit the FBG.
Posted Tue 10 Dec 24 @ 11:22 am
must be different to the version I have, it's a solid 4/4 at 88.65 here.
Posted Tue 10 Dec 24 @ 11:41 am
I personally thought/remember the studio track being a constant BPM too - maybe they're referring to a live version?
Posted Tue 10 Dec 24 @ 12:49 pm
I agree,I almost always have to sort out the beat grid of my vinyl recordings because the built in detector is substandard when anylized first time,even then when playing the track beat grids are way out.
Posted 6 days ago @ 2:19 am
Yes, the same happens to me.
Posted 6 days ago @ 8:19 am