Noel Borthwick

There have been no changes to Plug-in manager recently. All it does is utilize the VST scanner for scanning but as has been mentioned numerous times, all scanning should be done from Cakewalk not plugin manager. We don't maintain or test scanning from plug-in manager and the scan functionality from there will be removed soon. There are many other improvements to scanning such as sandbox scanning that are only available from the Cakewalk preferences dialog. We'll look into why this happened but please use the standard preferences page for scanning, which has been the preferred way to do it for many years.

@mgustavoWe'll investigate it for a future release. Thanks for testing it.

Yes exactly. Please don't manually remove DLL's from those folders that you are not aware of since you will likely break existing VST3 plugins. Vendors may have necessary helper dlls there. My point was that you should not install VST2 plug-in's there.

@rv729 How did you end up getting your VST2 plugins placed in the reserved VST3 folder? Actual plugins in that folder should always have the .VST3 extension. You should never install VST2 plugins in the VST3 folder since it will no longer work. As of 2019.01 we exclusively scan VST3 plugins in the Program Files\Common Files\VST3 folder. This was done because some vendors install child DLL files for their plugins there and scanning these dlls cause other problems.

Please send the dump file for analysis. Your issue may not be the same problem

@Steve KatsikasThere is something strange going on with that project leading to a MIDI buffer overflow. I'll have to spend some time debugging it on Monday. This happens in older versions of Cakewalk as well. I went back as far as September and also tried SONAR which hangs with that project.

@Terry Kelley your dump files indicate heap corruption. I see that you are running outdated Microsoft runtimes for the VC redistributables. Here are the time stamps you have: mfc140u.dll *C:\Windows\System32\mfc140u.dll 14.16.27024.1 11/7/2018 1:49 PM VCRUNTIME140.dll *C:\Windows\System32\VCRUNTIME140.dll 14.16.27024.1 11/7/2018 1:35 PM The ones we redistribute are from a later date so your system isn't up to date. The versions from the Cakewalk installer are as below: mfc14u.dll 14.20.27508.1 3/8/2019 vcruntime.dll 14.20.27508.1 3/8/2019 Please do an install of the latest VC redists by following this link. After ensuring that you have more current versions of these files please redo the test and see if it crashes. I'm not sure if your crash issues are related but having old redist files can definitely cause crashes and other incompatibilities.

This really looks like memory corruption. What plugins or synths are you using in the project? I see that TTS1 is loaded. Also there are a ton of different ASIO drivers on your system. If its basic can you share the project so we can try and repro? What happens if you remove TTS1 and instead use a different synth does it still crash? What sample rate are you running at?

Depends on what you mean by more efficient Having a single instance is more memory efficient obviously. However its not the most CPU efficient since the DAW has no way to process each channel on a different core. If you are running into bottlenecks splitting it up into individual synths will give you a lot more CPU headroom.

@bvideoYou can read more about our patented plug-in load balancing here. A fundamental requirement of load balancing is for there to be 2 or more serial plugins that can be processed in parallel. Synths in the synth rack are SOURCES. The synth audio processing must take place individually for each synth before any further signal processing in the downstream circuit is performed. i.e. synths get fed MIDI data not audio and produce audio which is then sent to the tracks sourced by the synth. Its no different from recording audio or input monitoring in that regard. So load balancing doesn't apply here. Any parallel processing for synths has to be done within the synth itself by parallelizing the processing of its voices. This cannot be done by the host since it requires the plug-in vendor to do this. Its a double edged sword even for the plug-ins that attempt to do this however, since the threads in the plug-in start to compete with the DAW's threads and this can lead to other performance problems. I had a proposal many years ago to solve this problem but it requires cooperation with plug-in vendors to implement. For now the best way to do this if the synth doesnt support parallel processing internally is to have per channel instances of the synth and make one instrument track per channel. This way the DAW will manage the parallel processing since each synth voice will be farmed out to its own core. Of course this is a trade off between RAM and CPU performance because inserting multiple instances can take more memory depending on what samples are loaded etc. Hopefully the synth vendor internally optimizes this and shares samples between multiple instances of the synth. For TTS1 the extra memory would be negligible. TTS1 is pretty lightweight so I don't think it would be necessary to split into multiple instances typically.

@paulo There are some more WASAPI improvements in 2020.01 (esp for exclusive mode) so please try it there as well. What output device are you when using the mic in Cbb? This is important because both the output and input have to support the same sample rate and bit depth for it to work. The fix I am referring to has to do with how some devices deal with 16 bit audio. We had a case where a device would only work when the bit depth was set to 24 bit manually. This has been fixed in 2020.01 and such devices should now connect properly. Let me know if updating fixes this issue. If you are still having a problem PM me and we can do some more troubleshooting.

The MIDI tracks themselves don't take any significant processing load. When processing the audio track is where the actual plugin processing takes place. If you have a single synth all the processing work gets done on one core. So your PC specs wont guarantee no glitches since only a single core is being utilized. If that one core cannot complete processing (the data from all 16 MIDI tracks) then you will get late buffers and glitches. There is no way around that other than the synth doing some work on their end. How you can utilize more cores is by creating separate SI tracks for of Sample that each handle a single part. Though this is not as memory efficient it will significantly reduce the load for any core. Also each instance of ST will be processed by a different core in parallel so it will be a lot more efficient. Try it and let me know if it solves the glitches.

@Skyline_UK This is caused by excess load being consumed by SampleTank. This has no bearing on your audio interface directly. If you have a single audio track feeding the synth this means that all the work is being done by a single core. If it takes longer than the deadline to process the buffer you will hear pops and clicks. Smaller buffer sizes mean there is a shorter time limit to process buffers and if the synth takes longer it will glitch. >>my engine load flickers between 70% and 90% followed by a figure in brackets of 102% to 105% once I start Play The figure in brackets is the MAX engine load since playback started. So if its > 100% it means that some buffers took longer than the max allotted time. You should be seeing late buffers reported for this case. One thing you can try in this use case is see if plug-in load balancing helps. Load balancing will use extra cores to process the plugin buffers so it should help in the case when you want to work at 512 or 1048 samples. Assuming that the plugin is well behaved with multiprocessing of course.

@Steve Moddelmog I looked at all (well several) of the dump files you sent. These are all 100% plugin crashes - the stacks are not even remotely in Cakewalk code so its not something I can analyze further. The crashes are all in a shared plugin dll that they are loading called Chromaphone 2 Shared.bin. I suggest that you get in touch with AAS and give them the same dump files. They should be able to analyze why the plugins are crashing since its within their shared plugin code. I know the AAS guys well so if they need any assistance from us ask them to contact me. Its likely some incompatibility or a bug in the plugin thats being exposed under some conditions on your system. I've included some relevant snippets from the dumps. One more thing suspicious in your dump files. I see that you are running outdated Microsoft runtimes for the VC redistributables. Here are the time stamps you have: mfc140u.dll *C:\Windows\System32\mfc140u.dll 14.16.27024.1 11/7/2018 1:49 PM VCRUNTIME140.dll *C:\Windows\System32\VCRUNTIME140.dll 14.16.27024.1 11/7/2018 1:35 PM The ones we redistribute are much later so I'm not sure why your system isn't up to date. Maybe you reverted the install somehow or another app put old files there. The versions from the Cakewalk installer are as below: mfc14u.dll 14.20.27508.1 3/8/2019 vcruntime.dll 14.20.27508.1 3/8/2019 Please do an install of the latest VC redists by following this link. After ensuring that you have more current versions of these files please redo the test and see if it crashes. I'm not sure if your crash issues are related but having old redist files can definitely cause crashes and other incompatibilities. 'Untitled_01312020_125802.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x0000000054EE4660 (Chromaphone 2 Shared.bin) in Untitled_01312020_125802.dmp: 0xC0000005: Access violation reading location 0x0000000066B15180. 'Untitled_01252020_092413.dmp' (Minidump): Loaded 'C:\Windows\System32\explorerframe.dll'. Unhandled exception at 0x00000000A8FF834C (Chromaphone 2 Shared.bin) in Untitled_01252020_092413.dmp: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. ntitled_01262020_184418.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_184418.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x00007FFE4A80A839 (KERNELBASE.dll) in Untitled_01262020_184418.dmp: 0x20474343 (parameters: 0x000000007D5DF370). Untitled_01262020_185903.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_185903.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x0000000072754660 (Chromaphone 2 Shared.bin) in Untitled_01262020_185903.dmp: 0xC0000005: Access violation reading location 0x000000000078A180. 'Untitled_01262020_190505.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_190505.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. Unhandled exception at 0x0000000071784660 (Chromaphone 2 Shared.bin) in Untitled_01262020_190505.dmp: 0xC0000005: Access violation reading location 0x00000000722E8180. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Chromaphone 2.vst3'. Module was built without symbols. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Chromaphone 2 Shared.bin 64\Chromaphone 2 Shared.bin'. Module was built without symbols. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*c:\program files\common files\VST3\Ultra Analog VA-3.vst3'. Module was built without symbols. 'Untitled_01262020_195535.dmp' (Minidump): Loaded '*\\?\C:\Users\User\AppData\Local\Temp\Ultra Analog VA-3 Shared.bin 64\Ultra Analog VA-3 Shared.bin'. Module was built without symbols. Unhandled exception at 0x00007FFE7027A839 (KERNELBASE.dll) in Untitled_01262020_195535.dmp: 0x20474343 (parameters: 0x000000008AA21B50).

Another way to do this is to SOLO the MIDI track which will auto solo the synth audio track. Then bounce to track without a selection. The reason why it requires a selection of the MIDI track is the operation doesn't know which MIDI tracks you may want to include in the bounce. I think we can improve this by being smarter and auto selecting all associated MIDI tracks if nothing is selected, to avoid confusion like this.

This looks like a memory leak leading to this. Can you reproduce this by just creating a project and inserting Revo Pro?

Hi @Steve Moddelmog can you please send me a dump file to analyze? Here is info on how to capture a dump file for a hang.

@rv729 can you send me the log file please - which directory name is being skipped specifically? Where are the toontrack plugins installed?

Will send you a PM to try and get to the bottom of why you are getting a Win7 warning. Nobody else has reported this yet so we'll have to do some further troubleshooting. Regarding the crash its unlikely to be related to this release. Can you zip the dump file and upload it to any file share and send me a link please?

the new mode is completely independent of the other modes so should be fine going back. The new mode can use threads differently from prior modes since it supports task stealing. Did you also get the clicks with load balancing turned off? Maybe it exposes threading issues in that Kontakt instrument.

@Terry Kelley You are running win 10 and got this install warning? What flavor and version of Windows 10 are your running?

@Matthew Sorrels I doubt the final release had anything to do with it. There were a few completely unrelated fixes. Loadbalancing could potentially impact certain plugins negatively is one thought.

You can reload the ASIO driver manually in Cakewalk at any time by pressing CTRL and clicking the Reset button. However when I have seen this happen this doesnt solve the problem. Some devices physically need to be power cycled. Its a hardware/driver issue.

@JL Hmm I havent run into that. Does it only happen with the aggressive mode?

@noynekkerLate buffers is just a term I cooked up to indicate buffers that took too long to process. If you aren't seeing any late buffers it means that you aren't hitting any limits and that the CPU is able to process all workloads ahead of time. I will write an article about it later but in a nutshell it works like this. For each audio buffer, the audio engine allocates workloads for processing all tracks, buses etc to cores. It then waits for all the cores to finish processing their workloads. After the cores finish their work the final mixed audio buffers are delivered to the audio driver. Then the process repeats for the next buffer. If for some reason ALL workloads take longer to process than the deadline for the buffer (deadline = audio latency in milliseconds) the driver will get its buffer late. Hence its called a late buffer. Late buffers are shown in the CPU metrics. While a few late buffers will be completely imperceptible and shouldn't be anything to be concerned about, if you are getting hundreds of late buffers you should probably raise your latency. Higher latency means the deadline is longer and it gives the CPU more headroom to finish processing.