Noel Borthwick

Its a track template not a clip template. Clip data is not included.

There isnt anything in the new build that would change sound quality of recordings coming from your audio interface.

Correct. They're is no such thing as input dithering. Dither is applied on playback at the final stages when the float mixed data is down converted to 16 or 24 bit audio. ////this also happens on export. During recording we write the raw audio data that comes from the audio interface.

Please read this article for guidelines about reporting crashes.

If you are getting issues with copy paste and move its likely something very data specific with your project, rather than your hunches about unstable code. The best way to to troubleshoot is to get us/support a copy of your project with some steps on how you typically repro it. Also in your video the app is closing without a message - that is typically the result of an unhandled C++ exception from the UI, or heap corruption. Check if a dump file got created by Windows at the exact time of the crash in the minidump location, and send it to us. If not, there are also more advanced troubleshooting steps that can be taken by running WinDbg to capture the crash. See this article for information about capturing minidumps.

Good troubleshooting. This should be reported to izotope. It's not a Sonar issue.

Not necessarily since the dll is still loaded and likely corrupt. Try closing the project and opening it again and then insert ozone and see if the problem persists.

We have been working with both Microsoft and Qualcomm for Snapdragon / ARM compatibility and now have optimized builds for both Sonar and Next that run natively on ARM64 processors. This is great for users who want a laptop solution that is powerful and yet battery efficient. Desktop solutions are coming soon as well. There are already some ARM64 ASIO drivers available and many other vendors have them in the pipeline. Later this year Microsoft will be releasing an inbox ASIO driver that will work with any USB2 class compliant audio interface so it will be more widely available even for older audio interfaces. Note that you can also use onboard audio through WASAPI and it works well with the Snapdragon builds of Sonar. See this great video that Qualcomm put out featuring us. If you already have a compatible CPU you can download an ARM64 build of Sonar from the above link.

Fundamental differences in the engine. Next was designed from the onset to support mixed sample rates in the project and do real time SRC. It can even stream compressed audio files.

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.

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).