Is it :959 on the dot?
Does the tempo matter?
When adding "samples" to the timeline ruler, does that give any clue (e.g. in relation to configured latency)?

Sonar does this in 8.53 also.

Hi, i have the answer. I asked this over a year ago in the Steam Forum of Sonar. Read it here: http://steamcommunity.com/app/293140/discussions/0/412446890551877957/
 
The answer from Support was:
 
There's a known issue with BitBridged synths being frozen and not having the renders adjusted for the reported asio latency. The larger your latency is, the bigger the de-sync you'll see.

There's currently a few workarounds.

1) Use 32-bit SONAR when manipulating 32-bit only synths and bypass bitbridge.

2) Bounce the track instead, and setup a Process > Nudge command to be your exact buffer size (which you can find under Edit > Preferences > Audio). This is one feature you don't get on a frozen track.

Freezing is already doing a bounce, but you don't get as many editing options as you do when it's a regular clip. 

Personally, I never use freeze anymore because of the limitations.

3) You could switch to a different driver mode during the freeze/bounce down.

I know these aren't perfectly ideal, but you should be able to get past your block point and continue working.

FWIW: Dropzone is a very light synth. I just testing with over 10 instances of it on a VM and didn't see the performance change much. You could probably get away without freezing on it in most projects. Z3ta+2 on the other hand is a very intensive synth and if you're having problems I would definitely recommend freezing/bouncing.
 
 

killerbee1985
Hi, i have the answer. I asked this over a year ago in the Steam Forum of Sonar. Read it here: http://steamcommunity.com/app/293140/discussions/0/412446890551877957/
 
The answer from Support was:
 
There's a known issue with BitBridged synths being frozen and not having the renders adjusted for the reported asio latency. The larger your latency is, the bigger the de-sync you'll see.

There's currently a few workarounds.

1) Use 32-bit SONAR when manipulating 32-bit only synths and bypass bitbridge.

2) Bounce the track instead, and setup a Process > Nudge command to be your exact buffer size (which you can find under Edit > Preferences > Audio). This is one feature you don't get on a frozen track.

Freezing is already doing a bounce, but you don't get as many editing options as you do when it's a regular clip. 

Personally, I never use freeze anymore because of the limitations.

3) You could switch to a different driver mode during the freeze/bounce down.

I know these aren't perfectly ideal, but you should be able to get past your block point and continue working.

FWIW: Dropzone is a very light synth. I just testing with over 10 instances of it on a VM and didn't see the performance change much. You could probably get away without freezing on it in most projects. Z3ta+2 on the other hand is a very intensive synth and if you're having problems I would definitely recommend freezing/bouncing.
 
 

Bitbridge is not involved in my case.

timidi
Sonar does this in 8.53 also.

Haven't tried 8.5, but I did do the same TTS-1 experiment in X3 and the frozen clip start time is identical to the midi clip.

paulo

killerbee1985
Hi, i have the answer. I asked this over a year ago in the Steam Forum of Sonar. Read it here: http://steamcommunity.com/app/293140/discussions/0/412446890551877957/
 
The answer from Support was:
 
There's a known issue with BitBridged synths being frozen and not having the renders adjusted for the reported asio latency. The larger your latency is, the bigger the de-sync you'll see.

There's currently a few workarounds.

1) Use 32-bit SONAR when manipulating 32-bit only synths and bypass bitbridge.

2) Bounce the track instead, and setup a Process > Nudge command to be your exact buffer size (which you can find under Edit > Preferences > Audio). This is one feature you don't get on a frozen track.

Freezing is already doing a bounce, but you don't get as many editing options as you do when it's a regular clip. 

Personally, I never use freeze anymore because of the limitations.

3) You could switch to a different driver mode during the freeze/bounce down.

I know these aren't perfectly ideal, but you should be able to get past your block point and continue working.

FWIW: Dropzone is a very light synth. I just testing with over 10 instances of it on a VM and didn't see the performance change much. You could probably get away without freezing on it in most projects. Z3ta+2 on the other hand is a very intensive synth and if you're having problems I would definitely recommend freezing/bouncing.
 
 

Bitbridge is not involved in my case.

Are you sure? 
 
Do you use Sonar x64 (64 Bits Version). If yes, BitBridge is involved when you use TTS-1. It's a 32 Bit Plugin i think.
 
When this is the case you have to use the 32 Bit Version of Sonar or you have to use a Instrument which is 64 Bits.

killerbee1985
 
Are you sure? 
 
Do you use Sonar x64 (64 Bits Version). If yes, BitBridge is involved when you use TTS-1. It's a 32 Bit Plugin i think.
 
When this is the case you have to use the 32 Bit Version of Sonar or you have to use a Instrument which is 64 Bits.

 
Yes.
 
Using 32 bit version, so it's not a bitbridge issue.
 
Thanks for trying to help though.

i thought tts-1 was a dx synth?

I had it too. Orchestral percussion hit from Sample Tank 3 landed more than a second away after freezing so I cant imagine ASIO latency settings have anything to do with it.

(for me) TTS-1 is a 64bit DirectX synth.  Synth1 is a 64 bit VST.  Both show offsets when freezeing.  There is no bit bridge involved with either.  And I'm running 64 bit SONAR Platinum 2017.07 on a 64bit computer. 
 
At this point though I give up on this.  Cakewalk needs to say something about it.  Either verify it is a bug or explain how it is a feature/side-effect/how it is supposed to be.