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.

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.

@gmpCan you send me the project in question?

You pressed scroll lock. That throttles ui updates

Check your mailbox

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.

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.

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.

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.

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.