Noel Borthwick

Theme editor is highly bitmap based so it won't work as is. There are no longer images to replace. The advantage is color changes are now much simpler with vectors.

>>"Annual" means no expiry / no deactivation after one year, just no further free updates after the year, right? Exactly. We were one of the few companies offering this model even in the SONAR days. How it works is you either pay for 12 consecutive monthly subs OR you purchase a one year subscription upfront. In both scenarios the last months version is permanently unlocked for you and you own it. This is essentially no different than buying an annual version of the software outright. Many people who dislike subscription are unaware that we always did this. Also, an advantage of monthly subscription was that once you crossed the 12 month boundary you could continue consecutive monthly subs for however long as you want and you would always own the last version you paid for. All subs are not bad and are actually better for some people who prefer paying in smaller increments. So definitely read the fine print. Disclaimer: To be clear I'm not saying that this is going to be our model. We're still very much working out the details here. I was quoting how it was done in the SONAR days and saying not all subscription schemes are the same.

Sonar itself will run as demo for a 15 day trial period.

@Sal Sorice this is not intentional. It's likely due to some domain changes with the new website. I'll notify the back end team. Can you access your products from your account page on the legacy website? EDIT: It turns out that Command Center is relying on the old cakewalk website which is actually now legacy.cakewalk.com. Unfortunately the only way to restore it to working is to update the command center app itself since the URL's are built into the code. That might take awhile to do since that hasn't been changed in many years. In the interim please use the account management at https://legacy.cakewalk.com/My-Account to update your old software if you need to get to it.

We're still hashing out the details of pricing/payment models. What bothers you most about subscription? It's essentially a pay as you go lease model and is beneficial for those who can't justify putting down a lumpsum of cash at one time... For those afraid of the software deactivating, there are models that allow you to purchase an annual (non-expiring) license. This is what we did in the SONAR days. An annual license is no different from buying the software outright.

Sonar is built from the identical codebase of CbB so no change there. What's new at least to start with is some new features and a massive revamp of the UI to make it DPI aware so it can run on higher resolution monitors without pixelation. Note that this doesn't change the UX in anyway other than new vector-based graphics and a crisper look. It will be supported and added to in the future unlike CbB which will not get all the latest developments that have gone in since the start of this year.

Pricing details are still being baked but it will most likely be a bundle.

No Next is a full desktop based cross platform app that integrates with BandLab. The web browser based daw is BandLab studio that already exists.

There will be another final CbB release with bug fixes. We're wrapping up the details on that...

Why can't you just click Quit in the plugin message? It appears to be asking for user input there. If you skip the project should continue loading but the plugin will be not active which shouldn't affect anything. You can then delete the plugin from the project.

There will definitely be more dev work. If anything, it's the ongoing work that has resulted in in this taking longer than our usual releases, and due to various reasons, some out of our control, schedules keep changing. Hopefully in the next few weeks you folks will at least learn more about why it's been taking longer. It's definitely not that we've been idling here One thing we've been attempting to work on (won't be in the immediate CbB update since work is still underway) among other big things is a big UI refresh to modernize the look of the application and support high resolution displays better, which is a huge undertaking that touches all the user interface. And this is only the tip of the iceberg but I digress.

@pulsewalk If you have a problem that is project specific as it certainly appears to be in your case, the only hope to resolve the issue is to send us the project file. In many cases we don’t even require the audio data to identify problems so you could try sending just the cwp file first. Cakewalk does not share user data with anyone so copyright should not be an issue here.

I have literally never heard of this issue. There is no “migration” unless you are loading really old projects from the 90’s with the wrk file format! Products from the X series all load natively since the project files are backwards compatible. You mention LUA scripts - that is not specific to Cakewalk perhaps some third party wrapper is throwing those errors.

Were you using the 32 bit version of X3? VST’s that loaded in prior versions should definitely load as long as they have been scanned in CbB. Check your scan paths.

Some notes. Make sure performance module is set to audio engine performance rather than system load otherwise its showing performance of the system as a whole not Cakewalk. The measurement of engine performance is an “estimate” so don’t read too much into the metering. There is no perfect way for an app to measure core performance at the app level in Windows. Its intended for troubleshooting only. The bottom line is whether you actually hear glitches. The app is at the mercy of the windows scheduler so we cannot control which core gets the most cycles. Especially with some of the modern big/little core CPU’s as well as hyperthreading this is not deterministic anymore. Also one of the cores gets assigned to user interface. The audio engine can get assigned to the same core being used by the UI by windows so its not abnormal at all to see more load on one core. Load balancing is not a perfect science so I wouldnt get too hung up on seeing perfect distribution of workloads. Depending on how your project is set up and the plugins its normal to see variances.

You definitely want to check out workspaces since this allows you to hide as much of the user interface as necessary. This is a unique customization feature in cakewalk that other daws do not have. You likely have the default set to the advanced workspace, that literally shows all of the UI. Try setting it to basic or mixing, or create your own workspace to your taste to show just what you need.

For the record. I connected to Michael's PC via teamviewer and resolved it. ActController was crashing on startup for some reason (likely the act data got messed up when he had the Nanocontrol) I found the crash by launching Cakewalk inside windebug which showed the crash site. Then I renamed his actcontroller dll and Cakewalk immediately started up. After that I removed it from preferences control surfaces, renamed the dll back and added it back to surfaces. Its working fine for him now. Windebug is the best tool to troubleshoot issues like this when the app is not launching or poofing because it will always show the reason for the exit.

@OddSox The file was not available when I tried to get it. We look at dump files in Visual studio directly since we have the symbols. Windebug also works. However. without symbols you won't see very much .

@fossile the actual issue isnt related to pan law. When you bounce with source category clips, it's running each selected clip through the entire signal flow and captures the "as heard" sound. However, when it encounters a mono clip with channel format mono (or follow source), the clip gets upconverted to stereo at the end of the bounce signal path and then it gets converted back to mono when writing the file. this is where the 3db gain comes into play. I've fixed this by compensating for it for the next version.

There is really no reason to install asio4all for an audio device that has a manufacturer provided asio driver. At best it will perform worse than the native driver. At worst it will cause pain because it grabs ownership of the underlying wdm driver and will cause grief if you use the native driver.

If you can upload the crash dump or PM it to me we can take a look.

@Christopher Hunt Technically ASIO is a wrapper on top of the OS native driver model which is WDM. i.e an ASIO “driver” vendor must also ship a WDM driver for Windows itself to communicate with the device. There is no other way. So every device that has an ASIO driver needs to support Windows using the device at the SAME time as a DAW uses it via ASIO. Some devices do this well and others handle it poorly. For example Windows may be using the device at one sample rate while the DAW is using it at another. A well behaved driver handles all these scenarios transparently. All MMCSS does is set an elevated priority for the driver thread. This tells Windows to not interrupt the driver when doing other tasks which is useful when operating at low latencies. Cakewalk has supported MMCSS from day one when it was made available in Windows. At the time it was not part of the ASIO specification at all and almost no drivers supported it directly except a few like RME. So Cakewalk would set the drivers thread to MMCSS mode automatically to benefit from this (controlled by the MMCSS flag). This setting however was for both Cakewalk as well as the driver, until our recent release where we made it granular so it could be independently switched off for the driver. The reason for this was to avoid certain (buggy) drivers that caused problems when forced to MMCSS mode. The ASIO specification now states that ALL drivers should run in MMCSS mode but its still widely not respected. Pretty much the wild west out there Its not surprising because its an internal option that end users shouldn‘t need to worry about. In reality that isnt the case Most drivers don’t have a checkbox for this so its very hard to find out if the driver supports it without using tools like Process Monitor and even so its hard to find the driver thread most of the time. In Cakewalk I added a status if you hover over the performance module that shows the thread priority. If its 18 or higher its typically means that the driver is in MMCSS mode. However the technique I use to detect it isnt foolproof (Microsoft doesnt publish a way to check this!) Always choose ASIO inside the DAW. If you can use a different device for windows its preferable since it eliminates one common problem from the equation, since some drivers don’t play well when used simultaneously. I haven’t had issues with RME being used by Windows and Cakewalk simultaneously however. See my above notes. The technique I use isn’t perfect so if the driver has actually set it to MMCSS sometimes we just get a failure code when trying to set it to MMCSS but I can’t conclusively know if its actually running in MMCSS without running process monitor,

This has never worked with certain video formats. It didn’t work in SONAR as well. I’ve fixed it for the next release.

If your send a link to your project I can take as look at it.

Its pretty interesting that the issue occurs only on an AMD machine. I'll look into it some more but adding tracks have much interaction with the audio driver so that part is puzzling to me. Unfortunately, we don't have any AMD machines anymore to run tests on or I would have tried it.