-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
BPM mutliplier should be using the current deck BPM rather than the file BPM #12738
Comments
This is a feature. We consider the smallest bpm change as the optimum to avoid chipmunk voices. |
Yes, that makes sense in the case you simply want to match track's BPM effortlessly, however if you have already adjusted the BPM manually previously and want them to remain in-sync going forward (if you change the BPM of one), wouldn't it make sense for it to consider the adjusted BPM instead, rather then make a big jump from 110 to 55 as soon as you enable the sync? If not as default, would you consider as a configurable behaviour? |
I can imagine to add an extra rule that uses a snap region for this case. A preferences option will be to strict probably. |
Somewhere around 5% should be more than enough to address my usecase. |
How would that work in the unattended AutoDJ case? |
I'm not sure I understand the usecase, does AutoDJ uses the |
If we look to the transition of these tracks in Auto-DJ: For the last track with 180 220 BPM would be better Rate + 22% You see that applying the current BPM will not work well in case of Auto DJ. But it seems we have actual an an issue in the initial case: +83 % rate slider is definitely too high. I will have a look. |
I feel like you might have misunderstood the bug I'm reporting. The other day, I was playing those two tracks together, and I wanted to increase the global BPM back to 128. As both track were already manually synch'ed (to 110) using the tempo fader, I made one of the deck sync leader, and as soon as I enabled sync on the other deck, the rate divide by two, before I even had time to adjust increase the plating rate of leader as I was hoping to do in my routine, making the mix very weird as that vocal (the following deck was a vocal) suddenly was playing twice as slow. I think the current multiplier logic makes complete sense as it is currently, but hopefully you will agree that the behavior I am describing is a bug. Currently, this is how I have fixed in my dev branch, and it still to work still fine with the normal sync behavior you are describing. It is defintely flawed and I would assume it needs more work.
|
It turns out that it is correct. When I sync the 120 bpm track to 80 it is shifted to 160, which is correct. When I now increase the tempo to from 80 110, the 120 bpm track is consequently playing at 220 bpm. This is really an extreme edge case. |
It looks like a simple patch works for you.
It fixes my surprising rate of +83 % at least. |
Sorry @daschuer I missed the notification. |
Bug Description
How to reproduce
Here is the usecase:
Deck A has a track with a BPM of 80
Deck B has a track with a BPM of 128
Adjust the BPM of deck A and B to 110 (using tempo fader)
Enable sync using
sync_enable
orbeatsync_tempo
Expected
The BPM multiplier should be
1
, and both track should keep the exact same BPM value (110 in the example)Actual
The non-sync master (of the channel calling
beatsync_tempo
) BPM of the non deck gets set to 55 (if it's A) or 220 (if it's B)Fix options
SyncControl::slotControlBeatSyncTempo
andSyncControl::reinitLeaderParams
could usegetBpm()
instead offileBpm()
if validbeatsync_tempo_absolute
andabsolute_sync_enable
While
1.
feels like a better fix, I guess it may also be a breaking change in some cases so I thought I will mention2.
although it definitely feels sub-optimalVersion
2.4.0
OS
All
The text was updated successfully, but these errors were encountered: