Noel Borthwick

Be thankful we give you diagnostic codes to help troubleshoot problems. Good luck getting that in other DAW's 😛

Lookup error code 5 here Try raising the playback I/O buffer size to 512 or so.

That's correct. Bandlab membership gets you both Sonar and Next so you can open your project in Sonar, export to cxf and then open in Next. Please read through the docs so you can verify what's supported via cxf. Most data will migrate, but features specific to Sonar won't go across so you may have to bounce a few things if so.

While AI generation is new, algorithmic music generation has been around for 30 years or more. Products like Band In a Box, Jammer etc have been used on countless productions and there haven't been copyright issues, at least any I have heard about. While there is some legit concern about copyrighted data being used for training LLM's, for music often the training data itself is algorithmic.

New versions of BA don't even allow downloading Cakewalk, and it does self update.

We’ll look into it. Can you share the Next project that throws the error?

Thanks for your interest and for signing up to use Sonar. I think you will be pleased with the improvements we’ve made to make it run much better even with moderate hardware. We’re aware of some of the confusion and looking into better ways to highlight the migration path for Sonar and Next to existing Cakewalk users, better trial offers etc, so stay tuned. Oh and BTW we have long discontinued the use of BandLab assistant to distribute Cakewalk software. The new product portal is Cakewalk Product Center which can be downloaded here. Product Center does allow you to download Sonar and Next directly from one central portal. Cakewalk Next is not intended to be the kitchen sink workstation that Sonar is today. Its primarily designed to be something that is most conducive to the music creation and ideation workflow, rather than production. However thats not to say that the product won’t keep evolving more in other areas. It already has some features that exceed the capabilities of Sonar. Its advanced Synth rack is one example where it can stack multiple synths within a single instrument track. Track groups too allow seamlessly mixing groups of tracks without the need to set up bussing. Also while Next may be new, it was built from the ground up to support all the multiprocessing smarts that Cakewalk is known for, and better. I don’t see any reason why it shouldn’t support large projects. The next userbase typically run with lots of plugins from what we see. Take a look at some of the demo projects in Next which may be fairly representative. Windows store is also something we have considered a while back. RE project migration, you can’t open CbB projects in Next but there is a brand new Cakewalk Interchange Format specifically designed to do this, which allows you to open Sonar projects in Next and vice versa. Of course Sonar opens any project from CbB or any prior version of Cakewalk.

No its independent public domain data. Songstarter was a Google partnership. https://medium.com/platform-stream/bandlab-launches-songstarter-an-ai-powered-tool-built-to-fix-musical-writers-block-1581577ec02 The AI team also creates specialty training data using their own proprietary tools as well. There is a lot of investment in this.

BandLab has a dedicated team working on AI music. SongStarter is one such product as well as stem separation. They are not yet available in Sonar but can be accessed via BandLab studio. Cakewalk Next does have access to Splitter. https://www.bandlab.com/songstarter https://www.bandlab.com/splitter But to answer your question yes we are thinking about fruitful uses for AI.

it's best to share a link to the project file and audio data since it could be specific to the data.

There are many changes to Sonar since CbB so a difference in behavior could be what's exposing a vulnerability in the plug-in. From the crash info there isn't anything for us to glean since the crash is exclusively in the plug-in code with no Sonar context.

@Tay Zonday both Cakewalk Sonar and Next are paid products currently only available via BandLab membership. This information has been available on our website for quite some time now. See screenshot. There is also an FAQ at the bottom of the page that explains more about membership.

I'm afraid I can't help with this. The plugin is crashing not Sonar. Send the dump file to the plugin vendor to analyze. If they need assistance or have questions about Sonar after looking into it they can contact me. 00000000ffff07dd() Unknown [Frames may be missing, no binary loaded for Listento.vst3] Listento.vst3!00007fff4752f707() Unknown

I’m not sure if this is applicable here but we have come across some problems with certain plugins that are flooding the Windows message queue to the point where it goes unresponsive. Windows has a 10000 message limit and if the queue is bogged down more than that it hits a “fuse” and messages get lost. We actually had some bizarre problems caused by plugins doing this that we had to mitigate against in Sonar. If you can reproduce this in the standalone app, you should report it to the vendor.

Zoom makes good interfaces. Not many audio interfaces support 32 or 64 bit inputs. The only one I came across many years ago was from Rane and that was a DJ mixer. It made sense to output in 32 bit since it was mixing internally. I’m sure you are aware but besides the advantage of flexible gainstaging (low or high input gain isnt a problem in float) there is no sonic advantage to 32 bit inputs since all ADC converters are up to 24 bit. Its clever that they have two inputs and choose the best level. Not sure how they handle that dynamically without levels jumping around but it seems plausible. However in this case you should note that the 32 bit inputs themselves are not giving you better dynamic range of the audio, since the convertors are still sampling 20-24 bit audio at the end of the day. My guess is that they are likely applying some gainstaging for whatever algorithm they use to combine data from two inputs and its more convenient to do losslessly in 32 bit. Still its a nice innovation. In Sonar there is actually an advantage to having 32 bit inputs from the audio interface. Since the engine is all floating point, all hardware inputs get upconverted to 32/64 bit depending on the engine bit depth. If the audio inputs are already 32 bit no conversion is necessary so this actually saves a bit of CPU.

@Bassfaceus Your dump file is for a hang and isn't from the latest release of Sonar. Also it contains no info that shows Sonar code hanging. I suggest updating to the latest Sonar release and retesting this there.

Can you send the crash dump so we can check if it's a plug-in crash?

Hopefully you can confirm this is fixed in the latest Sonar version…

This isn't totally accurate. In this case the malware is the old Microsoft redists themselves lol. Installers don't overwrite redists themselves. App installers just install the Microsoft redist installers. The problem is that old versions of the MS installers cause problems. Recently Microsoft started shipping universal redist installers but many companies don't seem to have caught on to this and are still using the old installers. This is the main source of the problem.

This. When you solo the track it figures out all the dependencies for the track and conceptually solos them as well. In this case the bus is a dependency for the track because you are sending to a side chain plug-in input in that track. So the circuit for that bus gets activated. This is the only way you can hear the side chain. If you don't want to hear that bus you can set it's output gain to silence.

The 2024.09 feedback thread is where you should post anything you think is specific to the new release, not in random threads.

Wasapi isnt a driver. Its the windows API to access all audio hardware drivers. Its the same API that windows itself uses. As long as a device exposes wdm drivers they should be available via WASAPI. WASAPI shared mode in particular goes through the windows audio engine, which is how it is able to handle multiclient use of a single audio devices. As a result it has a 10 ms latency. WASAPI exclusive doesn't have that limitation. Its not that WASAPI is perfect, but its the Microsoft recommended API for consumer audio devices. ASIO4All and some other similar products try and duplicate some of that functionality but introduce other problems because they wrap all other audio devices on the system and when Sonar starts up sample rates can get messed up with other devices among other problems.

I don't see any point in using a WASAPI to ASIO wrapper when Sonar already has robust WASAPI support. You are inviting more problems and bugs by doing that. If you have a problem that is related to our WASAPI support report it as a bug and we'll investigate it in time. A WASAPI to ASIO driver couldnt get any better latency than Sonar already gets from WASAPI. Its typically limited to 10 ms for USB audio devices in shared mode, and can go lower depending on the manufactures support for WASAPI. Unfortunately a few manufacturers don't support great latency in WASAPI and if so the only recourse is to use ASIO.

There is a new feature coming in the next release that would help with this very issue.

Yes the problem was related to the loop construction view preview bus. I've fixed the issue for the next release.