Noel Borthwick

If you are seeing crashes please submit a crash dump and we can take a look. Also please specify what audio interface and driver mode you are using.

Right, test using the native rme ASIO driver which is a solid driver designed for low latency. Testing performance metrics with onboard audio devices is futile since there are factors outside our control that can cause glitching irrespective of whether the audio engine is efficient or not. I will do some testing in Wasapi at some point and see if anything can be improved but for now we're focusing on ASIO and plug-in performance.

Both programs have identical config settings and use WASAPI shared, This is most likely the root cause of your problems. WASAPI shared has interactions with the Windows audio engine outside the control of Sonar. Also WASAPI shared isn’t performant at all with low latency. Esp with USB audio where it wont even go lower than 10 ms. Please do your testing with ASIO (and when I say ASIO ensure you are using a native ASIO driver - not ASIO4All) and with no other application using the audio device. Which audio interface are you running? Low latency performance is very dependent on the quality of the drivers. There is literally no way Sonar could be less efficient than Cbb engine since so much has changed under the hood.

The low latency performance improvements are unrelated to GUI. If you aren’t seeing a difference its almost surely due to differences in setup between Cbb and Sonar. You don’t specify your CPU and OS configuration but even with 8 cores there are measurable gains. Its important to note that any DAW level gains cannot magically eliminate CPU load caused by high load plugins. The easiest way to measure the gains in Sonar more quantitatively is to create a benchmark project. Add something like 100 tracks with about 4 similar plugins on each track then test it at various latencies by archiving tracks until you get no glitching. You can also do the test with instrument tracks if you prefer. Also observe Sonar’s performance meters and watch for late buffers and engine load. In Sonar we see up to 3X gains now compared to old releases depending on the project workload. Most beta testers and several users have already corroborated these results. The most obvious user visible one being that they can run their existing projects at much lower latency than before.

We stopped using that 20 years ago.

It could be the above issue. Some other app installers are installing obsolete versions of the VS redists and clobbering the latest install that can lead to random issues. If updating to the latest redist doesn't solve the problem, capture a dump file from task manager upload and send a link to the dump. You can read this article for more info.

This issue has been resolved for the next update…

You can try using snap by and setting the snap amount to samples and enter the sample value. Then zoom in and move the clip left till it snaps to the amount you need. Nudge is probably an easier way to do it.

@noynekker I've tracked down and fixed the issue with BFD3. This problem is actually not new to this release but happened in the August release. You likely never tried it until now in Sonar. The issue only happens in the old VST2 version of BFD3. When I first tested it in the new free BFD player groove playback it worked fine. We had to track down the old BFD3 and could then repro it. The issue is caused due to a very obscure reason - we optimized time reporting to VST plugins in July and one of the changes was incorrectly reporting the transport changed state. This seems to confuse that specific plugin and preview returns a repeating buffer leading to the distortion. The fix will be in the next release. However, for now a simple workaround is to run the Sonar transport. While the transport is playing, groove playback will work correctly in BFD3. Thanks for reporting this.

If you do the same test in Cbb does it crackle?

You can't expect reamping to phase cancel. Even with digital gear they are emulating analog equipment so there will always be random differences. As long as you don't have signals badly out of phase you aren't going to hear negative effects of phase cancellation anyway.

Is very unlikely that if is performance related it would do this in sonar but not cbb. Have you redone the test with exactly the same settings and project file in both cbb and Sonar? Make sure that both programs are using the same driver mode and buffer sizes. If after doing the test you are still seeing a difference then send a link to the project file.

Is midi output enabled for bfd? That's literally the only way that you could have midi feedback if at all. Sonar is not sending any midi if you are playing within bfd itself.

I'm not familiar with bfd groove editor. Is that built into bfd? If it's just auditioning grooves internally I can't see how anything in sonar could be the cause of a rendering problem within. Does BFD3 itself work ok for you? If you are using plug-in load balancing try disabling it. Some plugins get confused with heavy multi threading.

@Michael Crepps It may be helpful if you can zip and upload your project that exhibits this issue. You can PM me a link to to the file and we can investigate further. It's possible this is project specific.

Which driver mode are you running and which audio device?

The ICU theme will also have a check engine light and an oil gauge.

We already send the proper flag to indicate that effects are getting silence but many plugins don't bother checking it. Why not just turn off the audio engine before you leave the system. Sonar is probably the only DAW that allow you to do this so take advantage of that feature. Turning off the engine completely stops all audio processing so it will save power. Like turning off your car

@Michael Crepps Check if you have gpu acceleration enabled under Preferences | Customization | GPU acceleration. If so turn it off, restart the app and retest.

I recommend that prior to purchasing plugins ask if they have been tested in Sonar. If not, and you get an answer like that, vote with your dollars. We work with any plug-in vendor big or small that is willing to work with us on resolving compatibility issues, even when most of the time it ends up being a plug-in fault. If it's actually a host issue, we promptly fix it. Read this article for a course of action to diagnose plug-in compatibility problems.

By any chance do you have ExceptionHandlingSeverity set to anything but 1 in preferences | File | Initialization File? Reinstalling Cakewalk will have no effect on your projects. This looks like some Windows shell component is potentially corrupted or out of sync.

Something to note. You are using multiple voices in a single instance of Kontakt. CC7 is interpreted per MIDI channel so if you have multiple voices responding to the same CC perhaps this could lead to the behavior you are seeing. Another possibility for resolution is why not use Sonar’s volume automation for mixing instead of using CC7?

As I mentioned above the best test for issues like this is the phase cancellation test. Because it completely takes monitoring (and your ears) out of the equation. Route the kontakt track output to a master. Bounce the track itself. Now solo the bounced track and the kontakt track. Please invert one of them and play. You should hear silence or almost silence depending on if there were certain plugins used.

You can phase invert even with instrument tracks. Solo the instrument track and the boxes track and invert phase on one. If you attach a project file someone may be able to provide some clues.

Hmm I don't expect that to happen. I'll look into that.