Noel Borthwick

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

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

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

Indeed a side chain is internally a bus and will sum all sends to that side chain. Soloed buses are not coupled with tracks so if your solo a bus you will also need to manually solo other other tracks that aren't dependent.

If the internet is gone permanently, I think you will have far worse problems than not being able to use your DAW You can authorize cakewalk via the offline auth mechanism but yes that requires at least a remote internet connection somewhere. Pretty much most software today is tied to some sort of activation mechanism, its just how the industry has evolved.

For me any product its actually more than the sum of its features, but its workflow. If a product has a million features but the workflow doesn't suit me, I don't use it. Time is too short to waste on things that aren't intuitive to you.

Thanks for using Cakewalk software. It has grown by leaps and bounds over the last 4 years and is more stable and performant than it has ever been. In general, if any DAW meets your workflow and needs there is no need to keep endlessly looking elsewhere because you will waste more time learning new tools. And believe me when I say this - every product has flaws and bugs despite what you might hear from anyone else We're also working on something exciting that will be announced relatively soon so at minimum hold out until then ?

Thanks to some tests from @David Baay I have isolated the issue that causes the UI to be unresponsive after stopping when there are hundreds of tracks with certain prochannel modules. It is fixed it for the upcoming release. The issue is easily reproducible if you have 200 tracks containing the console emulator. The reason for the delay on stop is because the console emulator ends up blocking the user interface under certain conditions. I have worked around the plugin issue in our code. Edit: This fix is included in the 2022.09 official release.

@Antre I realize that it's frustrating when you have a problem that apparently doesn't occur elsewhere, but the truth of the matter with troubleshooting is ALL DAW's are vastly different and that a symptom that appears in one and not another doesn't necessarily shed much light on why this happens. As others have indicated there are a ton of moving parts that can lead to something like this. The proper way to troubleshoot is through a process of elimination: - Start by deleting tracks - you may be surprised to find that the problem occurs with one of the tracks. If so go further to look at the content. - Bypass or remove all plugins from the project. Does the transport still take time to start? - When you press play there are many things that happen as a part of the preroll process. One is opening and prereading to cache audio data for all the tracks. If you have many tracks (many hundreds) and there is a disk fragmentation or slow read issue this process can take a couple of seconds. Try playing with the settings in Audio | Sync and Caching. Setting a very large playback buffer can cause preroll to take longer. - Check if you have one or more plugins with huge delay buffers. If there is a large delay buffer, again preroll before playback starts will take longer because the engine cannot start playback until all plugins process initial audio. - Check if always open all device is enabled. If you have many I/Os enabled in preferences and the audio driver is slow it can take long to open the devices. - Check if Allow arm changes during playback and record is enabled. If its on depending on the number of inputs and the driver this can slow the preroll process down The above settings are the most typical reasons for lag starting playback.

Next update will include masking tape ?

Thanks for your support, guys. It is great that we are able to offer Cakewalk free to our users. As long as we are able to do so, enjoy it....

We can consider reducing the minimum loop size below 8th notes. A single tick resolution is too low. A DAW needs to do a lot more setup for looping than an audio editor or sampler so looping tiny region on the timeline is not as simple as it might look. Please move threads like this out of the release thread because its more suited to the feature request section.

Um you can do as much surgical editing as you need. Looping is not intended to be an editing tool. Use normal snap and zoom with the sample ruler to do surgical edits. Please move this to a different thread since its not related to this release.

There is nothing to fix because it isnt a bug. It is intentional that the loop length cannot be made smaller because there are problems rendering tiny loops. In any case there is no musical value in setting loops that small.

Hi Dave, With all due respect, I don't think it's a Cakewalk bug if your audio driver hangs the app However, your point is taken - within limits there are things that can be done to mitigate bad audio driver behavior. I'm not sure if it would help in your case however. In WDM mode we're at the mercy of how Windows drivers interact with the app if the driver deadlocks there isn't much the app can do. However perhaps we can remember an improper shutdown and reset the driver mode on next launch. Also did you already try launching in safe mode?

@Skoo How are you installing the instruments?

See this thread for the connection error issue.

As Scook said the web installer does similar checks to the in-app install process. All CbB versions from more than 6 months ago update seamlessly from within the app itself without needing to run the web installer manually.

Yes at some point we'll update to mix recall. Lots of stuff on our plate currently...

Cakewalk was the first DAW to add this in 2016. Cubase added it somewhat later but its not quite as powerful as our implementation.

Please stop using BandLab Assistant. For several months it's no longer been the mechanism to update Cakewalk. Use this link to get the standalone installer. Once you have a recent version there is no need for an installer since updates can be done inside the app itself by using Help | check for updates.

Anyone who was having this problem please install the latest 2022.06 Update 1 EA that we released. Even though the error 20 is caused by something completely external to Cakewalk, I've added some defensive code to the application that should prevent it from deactivating the application. (Something was causing the windows API's that read certificates to stop working. and this is what lead to the issue.) Please check it and report back ASAP if it solves the issue. Attn: @Wong Jian Ming @Mark MoreThan-Shaw @Illogistical Resource Dept. @mesabassman @Lombardi

Did you install the redist installer linked above?

Clicking solo in the mix module is a global operation to solo or unsolo ALL tracks. For soloing individual tracks or buses you have to click on the individual strip solo buttons.