msmcleod

When you use effects in your project, your computer has a small amount of time (a few milliseconds) to grab the audio data from disk (or from the output of a synth), run all the DSP code in all of your plugins, and send it on to your audio interface. The size of each chunk of audio data, and the length of the time slot it needs to process it in, is determined by the ASIO buffer size and your project sample rate. If your computer runs out of time before the next buffer is due to be sent to the audio interface, you'll either get clicks/pops/stuttering if it's just a little bit late, or a drop-out if it's really late. Doubling the ASIO buffer size doubles the time slot the the computer has to do the processing, but in most cases doesn't double the amount of time it takes to do the processing - i.e. it's not double the effort. Increasing the buffer size gives the computer more time to do the processing, preventing or reducing clips/pops/stuttering. That time it's been given is the latency between the audio being read from disk, and it coming out of your audio interface. So the downside of a larger buffer size is increased latency. Decreasing the buffer size has the opposite effect: it reduces the latency, but increases the likelihood of clicks/pops/stuttering as your computer has to work extra hard to get all of the effect processing done in a smaller amount of time.

You've obviously not been in the game long enough. Microsoft has changed their underlying driver model several times over the past 25 - 30 years. My Yamaha DS2416 cards were released with 16 bit drivers for Windows 95/98, but they later released 32 bit drivers for Windows NT/2000. These cards continued to work with the NT drivers up to and including Windows 7 32 bit. No 64 bit drivers were ever released, so I'm stuck with a Win 7 32 bit boot (with SONAR Platinum) if I want to load older projects. I did get 20 years use out of them though, which is pretty good. My 01X / i88x however didn't last as well. These had Windows XP 32 bit/64 bit drivers, which stopped working properly in Windows 7 64 bit. You can get it working on Windows 10, if it's running in test-mode and with a few driver hacks... not the best solution though. I have a bunch of Roland/Korg equipment that simply doesn't work in anything later than Windows XP 32 bit. As far as ASIO... it's not been my experience that custom ASIO drivers have been buggy - Realtek being the notable exception. The ASIO standard is more efficient than any of the other driver models, however WASAPI in exclusive mode does come pretty close (which is Microsoft's answer to Apple's CoreAudio). Ironically, the more pro the equipment, the less stable the WASAPI drivers are. RME for example has (IMO) the most solid ASIO drivers out there, with an incredibly low latency. Their WASAPI drivers are not good though. Focusrite have been pretty stable for me for the most part, with good WASAPI support.

From what I can tell, they used Spleeter (which is AI based) to separate John's voice from the rest of the music, but beyond that there's no AI. It reads like, "It's not John singing, it's AI" - but that's not the case. It is John singing - they just used AI to get rid of the other instruments. It's really not that much different from Queen's "Heaven for Everyone", which used Freddie's vocal track from the same song on The Cross's "Shove It" album. I've listened to both versions, and the vocal performance is identical.

AFAIK there is no modified driver to download, you just need to manually adjust the existing installation files so that Windows 10 will accept them. It's detailed here on the old forum: http://forum.cakewalk.com/How-to-use-V700-win-8-driver-in-win-10-also-applies-to-some-other-Roland-drivers-m3206046.aspx

@Robert Hale - can you post a screenshot of the application running? (CTRL + PrtSc will take a screenshot) This will clear up any confusion.

Different browsers? seriously? How that could possibly have anything to do with it is beyond me. I'd recommend re-installing the latest VC++ redists, which both CbB and many other plugins rely on: After installing the bundle that Noel links to, you could also try installing the latest one from Microsoft: https://aka.ms/vs/17/release/vc_redist.x64.exe (link taken from this page: https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 ) Make sure nothing else is running when you install these... you may also need to restart your PC after installing.

Despite CAL being deprecated long ago, we've no plans to change its existing behaviour for Sonar, so any CAL scripts that currently work in CbB will work without issue in Sonar.

I use both Windows 10 & Windows 11 - to me there's no difference when using CbB/Sonar. I'm stuck on Windows 10 for some of my machines due to the age of the CPU (one is a 3rd gen i7, the other a 6th gen i7), but personally I would upgrade them to Windows 11 if I could. I do however keep up to date with all Windows 10 updates. There's two schools of thought here (well probably more, but lets say two to keep it simple ) 1. You have a stable system running in Windows 10 - if it's not broken, why fix it?... but some day you'll stop getting updates. 2. Upgrading to Windows 11 gives you the latest features/fixes, but at the risk of upsetting your current setup (e.g. audio interface driver incompatibilities). So the real question is, what is more suited to you?

If all you're doing is exporting an entire mix (i.e. all tracks), by far the easiest way to do this is via the Export module, and not use the Audio Export dialog at all. You get the choice of project (the equivalent of selecting none), or Selection, and you just choose the output format from the menu:

They were never part of the Cakewalk Command Center, as they weren't "connected" products. For those older products, log in to your old Cakewalk account at https://legacy.cakewalk.com

Pressing the "Pause" button ( next to Scroll Lock / Prn Scr buttons) normally fixes this. The Pause button is used to toggle CPU throttle mode, which limits screen updates to give more CPU to audio processing if you start getting clicks & pops.

You can set it in either of these two places highlighted in red below (note that to see it on the track, you'll need to pick a Track Control Layout that actually shows the MIDI channel (shown in green): Setting the channel here will cause all MIDI events in that track to output at that channel, regardless of what channel is stored within the clip events.

Got a few of them.... made me chuckle while I was waiting...

AFAIK subscription for Windows 11 only applies to Windows 11 Enterprise Edition, and does not apply to either Windows 11 Home Edition, or Windows 11 Professional.

The selection is stored along with the task, and by selection I mean the tracks/buses checked in the right-hand pop-out view. If the selection is empty, then by default it'll include all tracks, whatever they may be at the time you run the task. So new tracks will be picked up by default. If the selection is not empty however, it will only export the tracks that were included at the time you created the task. If this is the case, to pick up new tracks you'll need to: 1. Recall the task 2. Add any new tracks to the selection by checking them in the right-hand pop-out view 3. Update the task I've just re-checked this behaviour now (using the steps above) and it worked without issue for me. If anyone has a recipe for this not working, please let us know and we'll look into it.

That probably explains why they're useless in the West Coast of Scotland. My condenser based A/C works like a charm though.

Also check that it's not just a stubborn build up of wax. A few years back I was getting only 3-4 hours sleep a night due to a high pitched tone in my ears that never stopped. My ears appeared to be clean, but turned out there was some wax deep inside that had hardened over the years. Regular use of olive-oil ear-drops over a few weeks softened it all up, and now I use one of those latex screw type wax removal tools a few times a day. The tinnitus has completely gone.

It's a P8B75-V, so around 2013. I actually had no issues with it for years with an i5-3570. When I upgraded to the i7-3770 (not the "K" variant), the occasional crashing started - normally with large file transfers. To be fair, the i7-3770 is literally the fastest processor that motherboard supports (well apart from an over-clocked i7-3770K) and I doubt many were using it when it was released.

The thing is, that those "coolers" are not real A/C's... you fill them up with ice & water, which gets pumped around the fan and the fan blows air through it. Yes, the air it blows is cooler, but it also blows out a lot of water vapour. On the days I have to use it, I'll get a max 20 mins before the water is luke-warm and its effectiveness is no different from a standard fan.... in fact, I'd say my standard 18" fan is far more effective at that point. My air-cooler is the same size as my real portable A/C ( 30" x 12" x 12" ).

If the crash is in the plugin DLL, then 99% of the time it's the plugin's fault. If it was the DAW (and sometimes it can be), then it would happen on far more plugins than just that one (and by far more I mean most). All VST plugins must conform to the VST2/3 spec, which is a list of functions they must implement, and some they may decide not to fully implement, but must refuse gracefully. For the most part (i.e. unless the spec says otherwise), these functions can be called at any time and in any order. In reality, a lot of plugin developers assume you will never call function "B" before you've called function "A". Their reasons may be that function B might not return reasonable results until you've called function A. However, that doesn't mean you shouldn't be able to call function B before function A, and it certainly shouldn't crash if you do. It should just fail gracefully, or ignore it silently. It maybe that the other 5 DAW's only ever call function B after they call function A, so the plugin developer might assume that's the norm and never bother dealing with any other circumstance... but unless they've tested with every DAW / audio editor / NLE, that's a big assumption. There are many different areas plugins can be called from, such as: - loading the plugin presets, either internally in the plugin, or from an external file - binding automation parameters - setting the initial automation value The order in which parameters can be read/written to can be completely arbitrary - i.e. it could be in parameter order, automation lane order etc... and the order of other calls such as setting the tempo, or other system wide settings could happen at any time. The plugin shouldn't make any assumptions about ordering. When they do - that's when crashes happen. As for the DAW vs Plugin blame game... put it his way... I have over 2000 plugins, and maybe 3 or 4 crash on me. There are probably 10,000+ plugins out in the wild. Should a DAW manufacturer test 10,000+ plugins to make sure every one of them works? And test them twice for both VST2 + VST3? And then you hack the code to make one plugin work, and that causes another bunch of plugins to crash... it's like a game of wack-a-mole. On the other hand, a plugin developer has to support maybe 20-30 DAW's. Should the plugin manufacturer test their plugin on every one of them? The plugin dev doing the testing obviously is the more reasonable scenario, but with 20+ DAWs? How much will that cost them to do that, and therefore you? The plugin dev will likely pick 5 DAWs at max - realistically only 2 or 3... and if that doesn't happen to be the DAW you're using, there's a possibility there will be issues.

I had one of those (a slightly larger version) in my office. I also have a thermometer in the room. Although I felt slightly cooler, the temperature remained exactly the same, but the humidity shot up. When droplets of water started dripping off the base of the guitars hanging on the wall, it was time to switch it off... What does definitely work is a big fan when there's an A/C working (rather noisily) in the next room, as it effectively sucks the cooled air from the other room into the one you're in. So that's what I use now.

FYI we'll be releasing a new version of the Cakewalk Command Center very soon to solve this issue. So please make sure you either comment out, or remove those lines from your hosts file once it's available. If left as is, it could cause CbB to de-activate in the future. [EDIT] - And here it is.... p[

From what I understand from the posts by the devs, other than the new UI update that's coming and probably a few new bells and whistles, this is going to be identical to the current CbB under the hood on launch. This is correct. It'll be just CbB with new images, high dpi support and a few extra feature enhancements. There is obviously some difference between rendering vector based images vs static bitmaps, but we'll be monitoring the performance of this closely as more of the application is converted over. There are a few approaches we can take to mitigate any adverse performance effects of rendering vector based images, should it become a problem.

Ironically, my (now pretty old) ASUS motherboard was having intermittent crashes until I slightly increased the CPU voltage. Now it's rock solid.

The transition to vector based images is taking several months. To support user vector graphics will require writing a completely new Theme Editor. We're not saying this will never be done, but it won't be done for the first release of Sonar.