Help - upgraded from and old CbB, now some VSTs don't sync to fractional tempo (like 139.77 etc.)

[Jan]

So I've been running an old CbB from 2019.09 (build 70) for ages. No issues. I have a couple of projects that have unorthodox tempos, like 122.52 and 139.77 (remixes of some older tracks). They worked just fine in CbB. Upon learning that CbB will be dead soon I installed Sonar Free (2025.07 - 31.07.0.063) today, opened the project with a 139.77 tempo and the arps from Sylenth1, Vital, Spire and Kontakt are out of sync after a while. They are all VST2 but that might not mean anything (Diva has no issues in either VST3 or VST2 version). Once I change the tempo to an integer value i.e. 139 it all works fine, it's as if they ignore what's after the decimal point. I'm devastated seeing as the CbB is on its way out. As I said none of those problems ever existed on that old CbB that I had. I am able to reproduce this in a blank project.

Is this a known issue? Is there a magical setting that I can flip?

1. Those VST arps are definitely tempo synced

2. Sonar tempo seems fine, I have a 139.77 BPM audio track in there and it sounds fine (nothing that would indicate Sonar tempo drift, no glitching, no pitch change)

3. Tthe metronome stays in sync with Diva, but Sylenth1 clearly lags behind (I set up a simple quarter note arp and I can hear that the first arp note starts falling BEHIND the first beat of the bar after a couple of seconds). I exported this lagging arp to WAV and measured the bar in a wave editor - it's approx. 1.728 seconds which amounts to 139 BPM. So it looks like the .77 of 139.77 is truncated for some reason when going to Sylenth1. None of this happens in CbB from 2019...

Attached is an example project (created in 2025.07), not sure if it's of any use, and an audio export of the metronome at 139.77 and Sylenth1 clearly (well... when measured going at 139. I am able to open this project in CbB and it works as expected, everything is in sync.

(a friend of mine posted this on r/cakewalk subreddit as well)

sync issues demo.zip

[Noel Borthwick]

Well look into this next week and see if we can repro it.

[Jan]

2 minutes ago, Noel Borthwick said:

Well look into this next week and see if we can repro it.

Thank you very much, is there any additional information you need for me? Or anything I can try? I guess I could check the latest CbB although I don't really want to mess my current 2019.09 install up

I'm not sure when my CbB reactivation is due (sadly I think the last one was in February, so the next one will be days after Aug 1st), I wish I could force it now (is that possible?) so that I could get those extra couple of months until this bug is fixed. Otherwise I'll have no way of working on my project as I'll be left with a dead CbB and misbehaving Sonar...

[Noel Borthwick]

Hi @Jan

I investigated this problem and was able to reproduce it with Sylenth1. It is indeed a bug and exactly as you suspected that the tempo was being used as an integer.
In October last year I heavily optimized time reporting for VST plugins to reduce CPU use and we now cache tempo to avoid expensive calculations.
However, I had a typo in my code that was returning an integer instead of the fractional tempo. This issue was not caught since most people tend to use integer tempos.

The bug is now fixed and will be in the next update that we release soon. Thanks for bringing this to our attention. I'll send you a build that you can verify.
 

PS: I PM'ed you a link to a build with a fix. Please report back.

[Jan]

On 7/8/2025 at 8:31 PM, Noel Borthwick said:

Hi @Jan

I investigated this problem and was able to reproduce it with Sylenth1. It is indeed a bug and exactly as you suspected that the tempo was being used as an integer.
In October last year I heavily optimized time reporting for VST plugins to reduce CPU use and we now cache tempo to avoid expensive calculations.
However, I had a typo in my code that was returning an integer instead of the fractional tempo. This issue was not caught since most people tend to use integer tempos.

The bug is now fixed and will be in the next update that we release soon. Thanks for bringing this to our attention. I'll send you a build that you can verify.
 

PS: I PM'ed you a link to a build with a fix. Please report back.

@Noel Borthwick I confirmed with both my original and test projects that the issue is no longer reproducible in the new build. Thanks a lot for fixing it so promptly!

Just as I suspected the bug has been lingering there for a while, but went unnoticed - not necessarily because of people using integer tempos (although quite possibly), but even if you are using a fractional tempo you might not notice it if you retrigger your arp often (chord changes or sth) - I have another project with a 122.52 BPM tempo, but since I retrigger the arp every bar it was not noticeable. In that 139.77 project I don't retrigger the arp at all.

[Noel Borthwick]

Yeah, there are subtle bugs that can go unnoticed for years, decades even. I've fixed bugs that have been there since 2005 or earlier.
And then some user comes along and sees the bug immediately due to something very specific in their workflow and says - this app has not been tested, <insert expletive here> 🙂
I actually just fixed one like that - a crash with no audio devices present that was introduced in 2013.

Anyway, thanks for reporting this so clearly. It was a pretty important one to fix.

[David Baay]

23 hours ago, Jan said:

Just as I suspected the bug has been lingering there for a while, but went unnoticed - not necessarily because of people using integer tempos (although quite possibly), but even if you are using a fractional tempo you might not notice it if you retrigger your arp often

... or you're not using tempo-synced FX or arps, which is my excuse for not picking it up.  Almost all my projects use fractional tempos because they're set from recordings made without a click, but I haven't used any tempo-synced FX recently. I'll have to add that to my regression watch list. ;^)

On 7/8/2025 at 12:31 PM, Noel Borthwick said:

we now cache tempo to avoid expensive calculations

Noel, does this mean there might still be subtle sync errors if the tempo is changing frequently by small amounts? I sometimes snap the timeline to every beat of a freely-recorded piece but leave all or most of the variability intact. If the piece lends itself to using  tempo-synced FX, that variation is likely to get flattened to a fixed tempo, but not always. Just curious whether your caching approach would accomodate that.

[Jan]

On 7/9/2025 at 10:07 PM, Noel Borthwick said:

Anyway, thanks for reporting this so clearly. It was a pretty important one to fix.

No prob, I don't think you should expect anything less from a fellow software engineer, I guess I'm just golden-ruling it