Noel Borthwick

@Mage_et_lent Cakewalk no longer actively supports Windows 7. If you continue to use it, it's up to you to ensure your Windows 7 has the latest fixes from Microsoft. As things are bound to break. Not sure if this is related or not but the latest update has code signed dll's using SHA256. Windows 7 did not have SHA256 support by default so if you don't have a fully patched version you may have incompatibilities. This article has some further info. https://support.microsoft.com/en-us/topic/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus-64d1c82d-31ee-c273-3930-69a4cde8e64f Again I'm not sure if your issue is related or not. We're not seeing any problems in our Windows 7 test. Without seeing your project file there is nothing we can do further.

Nothing in the dump file other than the line that says its heap corruption. I would try disabling the flush tails setting. Unhandled exception at 0x00007FFB7662F6A9 (ntdll.dll) in Cakewalk.exe.2592.dmp: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFB766997F0).

Not quite as crazy as Lord Tim's deep but I have a 35"curved screen LG that I use. The curve is subtle so it doesn't bother me. I wouldn't have been able to fit that on my desk if it wasn't curved.

Ah yes without symbols you can't find much. Hopefully he replies. Let me know what operation caused the crash in case you find out.

It has nothing to do with cakewalk not being able to process large projects tracks. 24 tracks in itself, is tiny. People are running literally projects containing 500 tracks. Even on a powerful machine if you put a single plugin that is expensive on a track, it can block processing for longer than the allotted time and lead to late buffers. This is because a buffer will be delayed even if a single tracks processing is late. Raise your buffer size and it will reduce or eliminate late buffers. Plugin load balancing can also help. Like others said if removing a particular track or tracks stops the late buffers, then something in that track is taking longer to process than the buffer quantum. If it takes longer than the time allotted playback will continue but you might hear clicks from your sound device because it is being starved. The late buffers is just a metric to help users diagnose why glitches occur. Try deleting the plugins in the tracks to diagnose.

@XBaker Hello Tom 😛 No, today the "default" instrument is hardwired to TTS-1 and its primarily there provide a default routing when opening MIDI files. However, the add track dialog remembers the last used instrument for the duration of the app session, so if you pick a different instrument, it will remember it. It just won't be listed under the default category.

For what it's worth, try turning off this setting by setting its value to 0. Some plugins don't behave well when we try and flush them prior to doing a bounce. Also please attach the dump so I can have a look at the stack.

Good. Hopefully the developer knows how to debug using dump files. It's always surprising to me but many plugin developers don't even know how. Edit: I see that @Scott Wheeler is the developer 😛 Scott if you need any information from our end or find that it's an issue related to Cakewalk don't hesitate to contact me.

Unlikely since that seemed to be the only issue in that project. Once I skipped that missing wave file name the rest of the project opened without errors. If it were disk corruption or badly saved, then there would be far more errors. In any case the fix I made will allow such projects to load properly. Of course, any clip with the missing data will be orphaned.

@sjoens Sorry for the late reply. I looked at the dump files and both crashes are in your soundblaster driver! Cakewalk isn't even doing anything at the time of the crash. This is purely in the driver. I suggest uninstalling their driver or troubleshooting what causes it to crash with the vendor. This is not related to the latest update. Unhandled exception at 0x000000006A800598 (CtHdAs64.dll) in Cakewalk.exe.21944 - Copy.dmp: 0xC0000005: Access violation reading location 0x0000000000000008. If you google CtHdAs64.dll you will see that it is from Creative Labs. This is the data on the file that caused the crash. CtHdAs64.dll *C:\Windows\System32\CtHdAs64.dll 6.00.100.2059 3/1/2016 4:34 AM

@IRAKLI KVANCHIANI The reason it crashes is that somehow your project was saved with the catalog of referenced wave files incomplete. One of the referenced files was saved without its filename. As a result, the code wasn't expecting that and crashed. This is literally the very first time I've ever encountered this problem, so it's not impossible that something corrupted the project file somehow. However, I was able to handle this condition gracefully in the code and your projects load fine now. We'll release an update with a defensive fix for this since we take data loss seriously. fixed files.zip Here is a zip with the fixed project files. Do you have any idea what you may have done that led to the files being saved incorrectly?

@Mage_et_lentCan you share a link to the project that has the slow load.

Even before you posted this I was going to ask if you had the cubase generic low latency driver installed. It has nothing to do with Cakewalk and multiple drivers. The generic low latency driver is a wrapper driver for WDM that tries to manage the audio device and causes bugs like this when cakewalk simply enumerates the ASIO drivers, which happens at startup time. Most likely what happens is this driver is initializing the device to 44.1 and conflicting with your settings in Cakewalk. You should report this to Steinberg.

The first thing I would try is open the exact same CPW on a different machine and see if you get that dropout. The dropout is unlikely to be related to the disk since the code is different for disk underrun errors. If you share a link to the project and its reproducible we can look into it. PS: Also I’m not sure if you are aware of it but you can completely disable dropout detection via preferences | configuration file. If its an intermittent dropout this might be useful to do.

No it has nothing to do with that. The only PC module that was (mistakenly) exposing MIDI was the console emulator. PC modules should never need MIDI.

@István Máté This is explained in the release notes: Are you saying that sends to hardware outs are affected? That’s not expected

If you are hearing glitching that goes away it would appear that the plugin is using enough CPU that is close to saturating one core/thread. Does raising latency improve it? Also try turning off load balancing esp if you are running at low latency. Load balancing is more useful at moderate buffer sizes.

If "Allow Arm Changes during playback/Record" is checked it preemptively prepares files for recording for all tracks with active inputs. If something prevents the files being created, you will get that message.

Can you send me a direct link to the dump file if updating the redists did not fix your problem?

Which version were you running prior to 09? There are zero changes that would affect audio streaming in 09 compared to 06. If you are seeing something its coincidental. Also, Windows 10 vs 11 presents no change to the actual code so we aren't doing anything different for Win 11 as far as audio goes.

Send us a crash dump file and it may help isolate the root cause.

Pretty unlikely to be directly related to this release, since there is a very bounded set of changes. Attach a crash dump and we can see what the cause is.

The reality is that it's an incredible amount of work to support any new protocol and deal with the inevitable bugs and confusion. VST3 is flawed in many ways and its design is a bit strange, but at least it is extensible. Decades ago in the 2000's, Cakewalk started an open plugin standard discussion with all DAW and Plugin vendors. The specification was in discussion for over a year, and nothing came of it despite it being way better than anything out there at the time. Often, it's not the best thing that sees adoption, there are many factors.

Yes, I just tried your project. As David mentioned, this is how the internal mechanics of bus solo works rather than a bug. It's incredibly complex to determine the dependencies that need to be activated when soloing something due to speghetti routing via sends and aux tracks etc. What happens is because the drum bus is sending to the sidechain input (which is actually a hidden bus internally) the drum bus gets activated as well. You could argue that it's a shortcoming of the intelligence of the bus solo mechanism, but it's not necessarily as simple as that. For example, the output of the drum bus might be indirectly feeding another sidechain of the track in which case there is no recourse but to output from the bus. In general, when it's determined that a bus is required for a sidechain the ENTIRE bus gets activated currently. If you need the bus output to be silent when soloing the track, set up the routing differently or mute the drum bus. The sidechain send will still be active in this case since its a pre-fader send. You can even use grouping to toggle the button states. TLDR: Combining bus solo and track solo is very complex especially if you have intra bus routing like sidechaining. It works for 99% of use cases but is not perfect. -- If you are interested, here is the net result of the solo states computation on my machine, after soloing the SI-Electric Piano 1 instrument track. The [x] means an output is active. You can see that the algorithm enabled both outputs on the drum bus (out 1 is the sidechain send) [x] 2 Master bus '--- None ---' [x] Out 0 [x] 92 Normal bus 'Master' [x] Out 0 [ ] 93 Normal bus 'Preview' [x] Out 0 [ ] 94 Normal bus 'Metronome' [x] Out 0 [ ] 110 <M> Track bus 'Matrix Data Track' [ ] Out 0 [x] 135 Master bus 'Focusrite USB ASIO: Output 1 + Output 2' [x] Out 0 [ ] 150 Master bus 'Focusrite USB ASIO: Output 3 + Output 4' [x] Out 0 [ ] 154 Master bus 'Focusrite USB ASIO: Output 5 + Output 6' [x] Out 0 [x] 156 Track bus 'LRS track bus' [x] Out 0 [x] 158 S Track bus 'SI-Electric Piano 1' [x] Out 0 [x] 159 S Track bus 'SI-Electric Piano 1' [x] Out 0 [ ] 160 Track bus 'SI-Drum Kit 1' [x] Out 0 [ ] 161 <M> Track bus 'SI-Drum Kit 1' [ ] Out 0 [x] 163 S Track bus 'Sonitus:fx Compressor(Side Input)' [x] Out 0 [ ] 164 Normal bus 'Drum Bus' [x] Out 0 [x] Out 1 [ ] 2047 <M> Track bus 'Track 6' [ ] Out 0

There is no pressing need to update the signatures on the dll's. Thats really the only change. There is no direct link to the full installer because it would be excessive load for everyone to download. If you really need it for some reason, contact support or uninstall and reinstall the application. You can also roll back 2 versions consecutively and then update again and it should fetch the full installer.