Noel Borthwick

The crash is fixed in the latest Sonar release. Worked around I should say since the actual bug is in the LP-64 not Sonar.

22 hours ago, Amberwolf said:

That's complete data loss, a situation that should never be allowed to happen by the code itself.  I would report this as a data loss bug.  The bakers may disagree, but:

If it could happen in the situation you had there (in a perhaps never-activated install of demo? post isn't clear about that part), it could also happen anytime a reactivation becomes necessary for any reason, including a program fault where it "forgets" it was activated because of whatever issue.

So a user could be working along, doing things normally on what for them has been an already-activated version of Sonar that the've been using for however long without issue, then they go to save, and because it has somehow become inactivated (reason doesn't matter), it has to be reactivated before they can save.   If at that time, the version being run has a required update available*** when activation is attempted, and it wont' activate and thus won't save before updating, all the user's unsaved work is now lost.

**** (are they all required?  Or can you skip them? I don't have direct experience with Sonar's updates, or have it to wait for them to come up and then test)

 

 

Data loss is a really big problem, to me (and presumably to most artists and other computer users).

 

I do everything I can to prevent it, saving often, always saving as new files never over the top of one, etc., using autosave, versioning, everything any program has to make it harder to lose data.   (and copying to external drives that are not connected except during backups, etc).   

But...a situation like the above could, even with frequent saves, still create a dataloss situation, if it came up. 

Completely incorrect information here. There is no way the program will switch from an activated state to a non active state mid session. The OP ignored the warning on opening the app and continued to work and saved much later. I'll add a persistent nag but if the user refuses to read warnings and doesnt save thats not the programs fault.

We'll look into it. Technically MIDI files are not "projects"

Thanks for sending dumps and data required to diagnose this. While most users wont be using such high I/O counts its easy to run into this problem inadvertently with software like VoiceMeeter that have virtual outputs. Sonar now handles upto 1024 I/O’s and if it exceeds that it will handle it gracefully without crashing

Can you try a different audio interface to rule it out? If you dont have anything handy use your onboard audio device.

Are you using any control surfaces?

Yes I meant pause. Both scroll lock and pause have been around for at least 15 years or more.

11 hours ago, gmp said:

I opened a CWP from 2010 since a client wanted me to work on it. In Sonar I couldn't open the synthrack and browser. Cakewalk support verified the bug, which if I had Sonar premium I could have fixed it by putting the Workspace as None. I found another solution, open CbB and save the file with the synthrack open. I'm glad this happened before 8/1/25

@gmpCan you send me the project in question?

On 7/10/2025 at 9:21 AM, Jan said:

P.S. Just noticed - while writing this - that when I came back to Sonar and hit "Play" the window would update only once per second (a slideshow essentially). Not sure what caused it. Maybe related?

You pressed scroll lock. That throttles ui updates

Check your mailbox

4 hours ago, msmcleod said:

From my conversations with Noel about this, unlike MacOS which forces you to use ARM64 plugins if you run as ARM64, and forces you to use x64 plugins if you're running in Rosetta,  ARM64EC will allow you to run a mixture of ARM and x64 plugins. 

What I'm not clear about is whether ARM64EC will run only ARM64EC & x64 plugins,  or ARM64, ARM64EC and x64 plugins.  I suspect its the latter though.

There will be a small performance  hit when running x64 plugins on an ARM machine though, as it'll be emulating the Intel code.

The performance hit is miniscule. In fact in some cases Prysm does an admirable job and it may even result in improved performance since its running ARM instructions not X86. From a battery life POV it will definitely use less energy running the plugin under emulation than an equivalent laptop on X86.

5 hours ago, pedwal wally wally wha said:

Early tests suggest that many x64-based VST3 plugins, including those from major manufacturers like Native Instruments and Waves, can be used on WoA, but iLok-protected plugins might not work, according to Steinberg Support. 

Well yes - ILok installs a driver. If they don't support WoA then the activation is not going to work. Has nothing to do with plugins themselves.
Besides drivers, there is nothing special required for running X64 code on arm for the most part (barring bugs in Microsoft's Prysm emulation layer itself). I found a few issues while porting and reported it to Microsoft.

3 hours ago, pedwal wally wally wha said:

just asked which plugins they tested with, keep yer wig on

We tested with the plugins we ship with and some of the normally used plugins like NI stuff etc. Thats like asking which plugins have you tested that work on Windows 11. Its not our call.

3 hours ago, Wookiee said:

You infer that it is the teams/Cakewalk responsibility to ensure someone else's product works with theirs. Why? There is nothing they can do if they don't, can they? They obviously make best efforts to ensure that their software is compliant with the standards of ASIO, current Direct X, VST 2/3, the current MIDI requirements, the currently supported OS's, the majority of Graphics standards. 

What I personally think you should be doing is asking the plugin creators what plugins work on the ARM architecture, that is the real first question to ask.

Then, and only then, if they say they are ARM compatible, but fail in you chosen host product, do you ask that products creator to resolve the issue. 

You are inaffect asking Cakewalk to ensure that their product runs on all the permutations of potential PC hardware combinations, plus test all third party plugins. When we know full well that Cakewalk, applies the latest SDK libraries to their products, but frequently third party creators don't test their products on all other potential hosts. I know this for a fact because when I have approached a number of third party plugin producers with errors. Their response is "Oh we don't test on xwz hosts." The most interesting thing with those plugins is, the Cakewalk team have identified the issue in the plugins creators code, and supplied them with the fix, whilst building a workaround into Cakewalk's code just incase they don't fix it.

Correct. Its not Cakewalk or any other DAW vendors responsibility to test every plugin in the universe. We test with the big suites and otherwise follow up when there are specific customer compatibility issues that are proven to be DAW specific problems. In any case this mostly doesnt apply to ARM 64 because Microsoft writes the emulation layer. If someone encounters a problem with a plugin not working on ARM, the first contact should be the plugin vendor.

5 hours ago, Grebz said:

What about third-party plugins? When you switch to an ARM-based computer, you can now use Sonar's ARM version, which is great, but do the plugins work somehow? I guess not, unless there are specific, available ARM versions of these plugins?

We're building Sonar as an ARM64 EC app which means its "emulation compatible". IOW it will run either native ARM64 plugins or normal X64 plugins in Prysm emulation mode. Prysm is Microsofts emulation layer that is part of the OS which converts between the X64 and ARM64 instruction sets.
All DAW's that host plugins or any third party libraries need to be ARM64 EC because otherwise these components will not load. Its very slick how Microsoft has implemented this so that it works seamlessly with classic X64 components.

The main caveat is that you cannot load X64 drivers on an ARM64 machine. You need native ARM64 drivers for that since there is no compatibility layer at the kernel level. In short, all normal plugins should work fine unless they do something dumb like check the OS version and fail.
We don't need to do testing with plugins on ARM, Its up to vendors to do their own testing. In my experience ARM64 works fine for all the plugins I tried due to the built in emulation layer. In fact you can see the TH-U plugin in the demo that Qualcomm put out showing Sonar on ARM. No changes were made to TH-U for that to work.

What is your driver mode and which audio interface are you using? Have you tried resetting your aud.ini?
If its happening in a blank project this has to be either settings or driver related. Definitely no code to delay stopping playback in Sonar other than what I showed.

Thanks, I've found the issue. The giveaway is that you can see the meters flicker when you click on a track. The flicker is indicative of some code that temporarily pauses audio. It's not a glitch but you hear a click when it resumes.

The pause was unintentional, but it was caused by a bizarre side effect of some UI code redesign that changed the order of some operations. I've fixed it now and will send you a build you can check soon.

11 hours ago, Matthew Carr said:

Does anyone else find that the Stop button on the transport (or by pressing spacebar) is now really quite laggy?

Playback starts instantly, but after pressing stop icon (or spacebar)

a) Playback stops instantly
b) The green play icon remains green, the stop icon remains grey
c) There is a delay of around 50ms. During this time it's possible to click on the start button again, but playback doesn't start until the delay reaches an end.
d) After the delay finishes, it's possible to press play again and playback starts immediately.

This means if I'm using spacebar to review a hit or short section of playback pressing spacebar works the first time with immediate playback. But after pressing spacebar to stop playback, I can't immediately press the spacebar to listen again - the delay kicks in.

No-one else is reporting this, so maybe it's specific to me - if anyone sees the same, pls chime in and will raise as bug.

Behaviour is the same for the pause button.

Using latest version of Sonar (build 84) with an XR18 interface in ASIO mode with a buffer of 128 samples (changing buffer size has no effect on this transport delay)

EDIT 1: Tested this on same project / hardware in CbB , and there is no delay when stopping playback.

EDIT 2: Tested this on same project / hardware in Sonar (31.06.0.048) , and there is a delay

Ensure that fade on stop is set to zero.

If you don't want it linked to Google you can do that via the BandLab settings. Support should be able to guide you on that. We have nothing to do with that setting.

1 hour ago, Stewart Kingsley said:

There is a miniDump file in Roaming\Cakewalk\Sonar\MiniDumps but its too big to attach (6.8Mb).

This is all described in the FAQ here that I mentioned earlier.

Sending the dump file to Cakewalk for analysis
Once you have the dump file you can put it on a share like dropbox, google drive etc. Next, log a problem report case with Cakewalk and include the link to the dump file. If a Cakewalk staff member has requested info you may also PM the dump file link to them directly this way.  Note: Dump files may include personally identifiable data so please do not post links to them publicly in the forums or elsewhere to protect your privacy.

@Stewart Kingsley Send me a PM and we can try and assist you next week. 

On 7/10/2025 at 3:51 PM, rayray said:

yes a guy with a brain.  sorry other guy but kinda critical mass for me right now,  i'm gonna wait until the last week in july to jump.,  that way i have everything done for ECO/BMI/MLC as far as mp3 exports. they will be close enough.  

i love CW and now gonna love SONAR most likely.  i need to take a look at the interface somehow before i actually load it up to see what i still recognize.

the most concern when jumping platforms is will all settings follow and such.

i hope the nags to buy premium are not too intrusive. i will buy it eventually - i don't need to be nagged to death to do it.

i am readin the forums to see what issues are being found.  they are doing builds so i may as well just wait.

 

Please read the FAQ on the Sonar website. These questions have been also asked and answered in scores of threads. Sonar is 100% compatible with Cbb projects themselves and will load them perfectly, often much faster than Cbb.

If you choose to use the free tier, only core application features are available for use. This is described in the FAQ.
Any other rare compatibility problems if found are addressed rapidly. If you intend to use Sonar its in your best interest to install it and check your projects ASAP. The app installs alongside CbB seamlessly.

@Stewart Kingsley did you check the crash dump folder and check timestamps? Even if there was no visible crash dialog it often saves the file there.

Sorry for the sign in troubles with CPC folks. I've identified the problem with the sign in for CPC.

It's caused because we cache state related to the sign in for the current product. However, if you change the product and exit the next time it fails to auto sign in.
We'll be releasing an update for CPC momentarily. Please update it asap and check if your sign in problem is resolved. 
 

Here is a link to the update if you want to try it before its posted.

Note: that the first time you run the update, it may force you to sign in but on subsequent launches it should now work correctly.

Please let me know if this solves your sign in problems asap.

Its all in the main post release notes. Its a ton of changes - read the entire thread.