locoDog
I have a couple of keys to double or half the BPM of a track so the effects make different sound, but I have noticed that sometimes (What I'm guessing is) float rounding errors creep in and the BPM is off by something small (but significant) like 0.20 bpm
Also reverse roll, When in the mix I'll use this with the beat grid effect to get a reverse quad beat (really quickly for only a single beat) and I've noticed that when disengaging reverse roll the track being affected slips, only by a fraction but it is noticeable.
Also reverse roll, When in the mix I'll use this with the beat grid effect to get a reverse quad beat (really quickly for only a single beat) and I've noticed that when disengaging reverse roll the track being affected slips, only by a fraction but it is noticeable.
geposted Thu 24 Apr 14 @ 11:03 am
jah love 36
you need to change the size of the bpm box in the xlm file
geposted Thu 24 Apr 14 @ 11:09 am
locoDog
I think I wasn't clear, it isn't the BPM correction box, that is not the concern, I don't use that, it is while playing and in standard mode if I double the bpm 4 times and then half the bpm 4 times the bpm number (in each deck's text zone) isn't what was there to begin with.
geposted Thu 24 Apr 14 @ 11:14 am
PhantomDeejay
The BPM of a song is an "attribute" Usually you don't change the attribute of a song for your tools/effects to work, but the other way around.
Anyway, in order to answer your question:
BPM value of a track is calculated as accurate as it gets and it gets stored inside VirtualDj Database as an INTEGER representing the distance between two beats in samples.
1 sec = 44100 samples.
Therefore a "44100" value in the database would mean 60 BPM, while 22050 would mean 120BPM
Doubling an integer will ALWAYS give you an integer.
Also doubling an integer X times and then halving an integer the same X times will ALWAYS result an integer.
However, halving an integer does not guarantee that the result will also be an integer and therefore rounds up have to be made.
Depending on how many halvings you do before you begin to double your values again you may produce significant round up errors
Again, that's not VirtualDj's fault. If you want to take a 130 BPM song and for whatever reason make VDJ think it's a 16.25 BPM song there's a flaw on the way you try to work with your tools.
Anyway, in order to answer your question:
BPM value of a track is calculated as accurate as it gets and it gets stored inside VirtualDj Database as an INTEGER representing the distance between two beats in samples.
1 sec = 44100 samples.
Therefore a "44100" value in the database would mean 60 BPM, while 22050 would mean 120BPM
Doubling an integer will ALWAYS give you an integer.
Also doubling an integer X times and then halving an integer the same X times will ALWAYS result an integer.
However, halving an integer does not guarantee that the result will also be an integer and therefore rounds up have to be made.
Depending on how many halvings you do before you begin to double your values again you may produce significant round up errors
Again, that's not VirtualDj's fault. If you want to take a 130 BPM song and for whatever reason make VDJ think it's a 16.25 BPM song there's a flaw on the way you try to work with your tools.
geposted Thu 24 Apr 14 @ 8:13 pm
locoDog
I see how the problem creeps in now
44100 = 60 BPM, 22050 = 120BPM, 11025 = 240BPM, 480BPM = 5512 = rounding error
I wouldn't have said doubling/halving the BPM is that revolutionary for changing how an effect sounds (it's quite elegant IMO), the alternative is to have several copies/keys, of/for each effect (not as elegant), but I can see how the error is pretty much unavoidable from a code perspective. Increasing the 'value' by a factor of 10 only gives one more 'doubling' before the error is apparent. So I'll have to live with it.
How about the reverse roll 'slipping' I mentioned?
44100 = 60 BPM, 22050 = 120BPM, 11025 = 240BPM, 480BPM = 5512 = rounding error
I wouldn't have said doubling/halving the BPM is that revolutionary for changing how an effect sounds (it's quite elegant IMO), the alternative is to have several copies/keys, of/for each effect (not as elegant), but I can see how the error is pretty much unavoidable from a code perspective. Increasing the 'value' by a factor of 10 only gives one more 'doubling' before the error is apparent. So I'll have to live with it.
How about the reverse roll 'slipping' I mentioned?
geposted Fri 25 Apr 14 @ 3:19 am