I often find that, in trialing blends with wide enough BPM difference (e.g. A track at 100 BPM and a track at 160 BPM), that the sync direction normally goes to the nearest multiple (e.g. if the 100 BPM track is being synced, it goes to 80 BPM and if the 160 BPM is being synced, it goes to 200), but often times that is not what is desired.
It would be helpful to have an option to change that behavior - providing an explicit direction for the sync, or at least to make the sync always be to the direct value of the master deck instead of to the nearest multiple.
It would be helpful to have an option to change that behavior - providing an explicit direction for the sync, or at least to make the sync always be to the direct value of the master deck instead of to the nearest multiple.
Inviato Sat 25 Apr 26 @ 10:35 pm
Yes please, I would like this feature as well
Inviato Tue 23 Jun 26 @ 1:41 pm
DJ VinylTouch wrote :
or at least to make the sync always be to the direct value of the master deck instead of to the nearest multiple.
So you're telling that a 148 BPM track should always slow down to 75 instead of going up to 150 when SYNC is used ?
Inviato Thu 25 Jun 26 @ 11:21 am
@PhantomDeejay I think the default behavior that was chosen is reasonable in certain cases (e.g. when you want to mix two songs in which one is roughly double time of the other, like when you are planning to do a tempo change, that is probably what is desired).
However, there are also cases where an exact match is desired - an example for me would when I have a blend of a properly gridded acapella or vocal stem of a much slower song (e.g. a reggae song in 70s to 80s of BPM) to a much faster song (e.g. an EDM instrumental >= 140 BPM) to produce a different kind of remix.
Having the direction of sync be controllable (a global option and probably even with an option to the verb itself, falling back to the global option default if not specified) would satisfy this requirement - nearest (the default, which is the current behavior) and exact (the new request).
However, there are also cases where an exact match is desired - an example for me would when I have a blend of a properly gridded acapella or vocal stem of a much slower song (e.g. a reggae song in 70s to 80s of BPM) to a much faster song (e.g. an EDM instrumental >= 140 BPM) to produce a different kind of remix.
Having the direction of sync be controllable (a global option and probably even with an option to the verb itself, falling back to the global option default if not specified) would satisfy this requirement - nearest (the default, which is the current behavior) and exact (the new request).
Inviato Thu 25 Jun 26 @ 11:57 am
I'm not against options / extra verbs / whatever.
But changing the one single behavior we have now would make the program unusable for 90% of people, to catter the needs of 10% of people.
I quoted a specific part of your post to make a point:
Permanent global changes should take into account the vast majority of use cases..
It's easy to think of one case and miss another.
Could there be an option ? Most likely yes.
Could there be a different action so that you can use both ways on the fly ? Even better!
But should the current default behavior change ? No, no way!
But changing the one single behavior we have now would make the program unusable for 90% of people, to catter the needs of 10% of people.
I quoted a specific part of your post to make a point:
Permanent global changes should take into account the vast majority of use cases..
It's easy to think of one case and miss another.
Could there be an option ? Most likely yes.
Could there be a different action so that you can use both ways on the fly ? Even better!
But should the current default behavior change ? No, no way!
Inviato Thu 25 Jun 26 @ 1:12 pm
I fully agree - this request was not me saying to change the default behavior because for the vast majority of the time that is not the right way (people are already accustomed/depend on that, and the current behavior is reasonable/works).
An option and potentially modifying the verb behavior to have that option is the best bet for me, while keeping the default option the same as what happens now.
An option and potentially modifying the verb behavior to have that option is the best bet for me, while keeping the default option the same as what happens now.
Inviato Thu 25 Jun 26 @ 1:19 pm
just script it
pitch accepts a beats param as a bpm
2 decks
or like this
4 decks is something else
pitch accepts a beats param as a bpm
2 decks
set_deck `get_deck & param_invert & param_add 3` & get_bpm & param_cast beats & set_deck `get_deck & param_invert & param_add 3` & pitch
or like this
get_text "`set_deck 'get_deck & param_invert & param_add 3' & get_bpm`" & param_cast beats & pitch
4 decks is something else
Inviato Thu 25 Jun 26 @ 2:01 pm





