Noel Borthwick

Yeah cant switch mid project in Sonar. However you can in Cakewalk Next since it supports hybrid sample rates in the same project.

You can run all our products offline. They however require to be occasionally activated which requires an internet connection. We also have an offline activation procedure to facilitate this.

John, you are conflating the ASIO driver and ARM64. ARM64 applications themselves require ARM hardware to run. The Windows ASIO driver is not connected with ARM although initially it may be released only on Windows ARM.

Yes because they are misleading to users.

This is an application hang and based on the two dump files you provided are not in Sonar code itself. One of your dump files is from an old release not the latest. The relevant information is below. In both cases the hang is in ucrtbase which is the windows universal C runtime. I assume that you are running Windows 11? Exception Code: CFFFFFFF (Application Hang) OS_VERSION: 10.0.26100.1 STACK_TEXT: ntdll!NtGetContextThread+0x14 ntdll!LdrpGetFromMUIMemCache+0x1cc ntdll!LdrResGetRCConfig+0x464 dbgcore!g_DownlevelShlwapiL1CallsDesc <PERF> (dbgcore+0x37048) ucrtbase!__crt_stdio_output::string_output_adapter<wchar_t>::write_string+0x4e ucrtbase!__crt_stdio_output::output_processor<wchar_t,__crt_stdio_output::string_output_adapter<wchar_t>,__crt_stdio_output::format_validation_base<wchar_t,__crt_stdio_output::string_output_adapter<wchar_t> > >::state_case_type+0x98 ucrtbase!__crt_stdio_output::output_processor<wchar_t,__crt_stdio_output::string_output_adapter<wchar_t>,__crt_stdio_output::format_validation_base<wchar_t,__crt_stdio_output::string_output_adapter<wchar_t> > >::process+0x169 ucrtbase!__stdio_common_vswprintf_s+0x1ba Based on this stack, I'm pretty sure you somehow have mismatched system dlls caused by something installing old components. You have a lot of third party plugins in your project. Perhaps one of the installers put a bad redist on your system. If this is the cause as it appears to be based on past problems like this, there isn't much we can do other than pointing you to this article to do a clean install of your redists. You can also try loading your project in safe mode and skip plugins to see if somehow one of them is causing the issue.

Potentially but only if it is a USB audio 2 class compliant device already. USB 1 devices are not supported.

There is no way that the latest update turned it on. Ripple edit has defaulted to off in every version of Sonar. You may have accidentally turned it on by clicking on the wrong menu item sometime. Keep an eye on this graphic to know if ripple edit is enabled. When its off it should show this:

I have the spark Mini and have recorded into Sonar with it using their ASIO driver. Recording works fine but input monitoring isn't great since the latency is too high with it.

Well X86 is not going to go away soon so there is nothing to worry about. Microsoft is heavily invested in ARM and the next generation of PC's is moving towards ARM so its good for everyone to have options. ARM is vastly more power efficient so very well suited to mobile use. Also there are some high-powered desktop ARM solutions on the horizon as well. https://wccftech.com/qualcomm-snapdragon-x2-cpus-to-feature-up-to-eighteen-oryon-v3-cores/ https://www.windowscentral.com/hardware/cpu-gpu-components/next-gen-snapdragon-x-elite-core-count-leaks-heres-what-we-know-so-far

Note that you need a PC has an ARM chipset like the new Microsoft CoPilot PC's or from another vendor. ARM software or drivers will not work on X64 hardware.

Most driver vendors would likely release ARM64 drivers soon I imagine. RME and Yamaha have shipping drivers, and I expect other vendors would follow. Even if your vendor doesn't release a driver my hope is that the Microsoft inbox ASIO driver would cover those bases. That would actually be cool not just for ARM64 but in general for devices that don't have ASIO drivers at all, resulting in some users using ASIO4All. Whether its bundled as part of the ASIO driver package or included separately depends on the manufacturer. Currently its a separate download from RME.

It's kind of low risk. X64 apps run fine on ARM64 devices via Microsoft's emulation layer which is actually surprisingly good. Today the main blocking factor is to ensure that your audio interfaces have ARM64 drivers. Once Microsoft releases the inbox ASIO driver this will be less of an issue. I'm running the RME ARM64 ASIO drivers and the Steinberg UR22. Both go down to very low latency 48 and 32 samples and can play without glitching on Next and Sonar for ARM64.

There will soon be no need for wrapper ASIO drivers or custom drivers that have no special functionality, since Microsoft is adding an inbox ASIO driver. From what I know, as long as you have a class compliant USB 2 audio device it will work with this new Windows ASIO driver. https://devblogs.microsoft.com/windows-music-dev/making-music-on-windows/

Regarding documentation are you sure you are referring to the latest documentation? You can access the online documentation from the help menu in Sonar itself. There is also the full documentation PDF here. Regarding TTS1 as others have said its no longer distributed both in Sonar and CbB since Roland discontinued it. If you had an old version of Sonar you could find it there. There are many free replacements if all you need is a GM instrument for demos or composing. One example is this.

Please respond in the linked thread.

Please respond in the linked thread.

We're beginning testing of ARM64 versions of both Sonar and Next. Please complete the poll if you have interest in using/testing these products. Also, if you would like to beta test these, please respond to this thread to add your name to the list. Read this to learn more about what's coming in Windows on ARM64 for musicians: https://devblogs.microsoft.com/windows-music-dev/making-music-on-windows/ The more interesting bullet there is the in-box ASIO driver which should work with most USB-2 class compliant audio devices on ARM (and X64).

Read this. There will soon be no need for wrapper ASIO drivers since Microsoft is adding an inbox ASIO driver which does things the correct way without hosing other applications. https://devblogs.microsoft.com/windows-music-dev/making-music-on-windows/

Recording at a higher depth that the interfaces provides is just padding silence.

You can't assume that necessarily. Its not that abnormal to have an issue which is driver or system related that only shows up with one DAW. Not saying that that is the case here but there is some environmental issue that triggers this that obviously most users never see. So you stop recording, the recording appears and then spontaneously disappears shortly afterwards? If you watch the wave data folder in file explorer while recording, do you see the file get created and then removed shortly after? Another thing to check is your recording drive. Check for disk errors and also check if you have any software (such as one drive) monitoring the folder where audio is recorded. If a program locks the file it can fail recording. Most of the times where people have encountered such issues it has been related to problems like this.

It most certainly doesn't force you to sign in via Facebook. The sign in process is identical for Sonar as well as Cbb or even the Bandlab web for that matter. It prompts you to sign in a very industry standard SSO (single sign on) page where you can sign in using whatever mechanism you chose when you created your BandLab account. This is what I see. You can use your username and password (assuming you create your account that way) or you can use Google, Facebook, Apple, or potentially SMS to sign in.

CbB has not been in development for over 2 years other than receiving a few updates for breaking issues. Please try this in Sonar and if you encounter the issue contact us.

You are free to draw whatever (incorrect) conclusions you may. There is no "campaign" to force anyone to update. You use old OS's at your own risk. We don't have the bandwidth to chase down obscure bugs that only affect certain systems on unsupported OS's. Our dev spent days if not weeks trying to fix issues that ended up being specific to your machine. Old versions of Sonar used completely different Microsoft tools so if it coincidentally worked for you there is nothing we can do to solve that. Upgrade to stick to old versions if you insist on running an old OS.

We cannot indefinitely support breaking changes to older operating systems. Windows 10 and Sonar work perfectly for 99% of users. Beyond that there isn't much we can do to support this. Changes caused by mismatched components or bugs in Windows itself are completely beyond our control.

Unless you have the symbols the function name will be meaningless. If you have a repeatable crash from a recent build of Sonar send me a link to the dump and I can check the cause of the crash. Sometimes dumps don’t give us the full picture…