Noel Borthwick

I don’t believe that the surface API allows for specifying the fader throw. We’ll look into it and see if there is something that can be done.

Thanks for reporting it. The symptoms look like heap corruption. We’ll try and reproduce it and follow up with the developer as well. @jon sasor [cakewalk]

Cakewalk requires you to log in once if you choose to activate it from within Cakewalk. It does not know that you are logged in to the bandlab website since that is independent. Similar for BandLab assistant, you must log in from the app. Its the same for all applications like spotify etc - if you run a desktop app it needs to be authenticated independently. Make sure you are running the latest version of CbB which is 2020.11.

@Michael Fogarty can you elaborate on what you did to fix the permissions? I have not encountered a windows update causing waves to not draw.

What is the repoted dropout code?

Correct, it uses pipeline parallelism to split the buffers and process them in parallel to achieve greater parallel processing even though the DSP pipeline itself has serial dependencies. I have a known limitation in the implementation that I hope to improve this year that may help improve performance when using it.

Good points. A few driver vendors create dependencies that cause unpredictable realtime behavior. Ive had this discussion even with Roland who claimed that background processing was the proper setup. Its completely counter intuitive to me since its now allowing any background process on the system to be given take priority over the DAW which means that audio processing could get less resources in theory! I’ve even discussed this with a systems engineer at Microsoft many years ago who said it was not a good idea to do this in general. Maybe @Pete Brown could verify this. Your theory that they have a (bad) dependency on some background process is possible. I’ve definitely seen drivers start to glitch when there is excessive activity on the UI thread - in theory this should NOT happen since the UI thread is running at much lower priority than the engine. Cakewalk’s UI is on the heavy side and I’ve been chipping away at reducing its footprint all of last year so it has helped but in an ideal world this should not be an issue. Regarding drivers that share this is likely because they are internally synchronizing to block processing until all clients have processed audio, similar to what WASAPI shared mode does because they have to mix all streams and potentially do SRC as well. Its not surprising that this scenario would cause some glitching. I wonder if the ASIO drivers that support multiclient access are running their mixing code in a different process. If so I could see how having background priority set could potentially change things there.

@forkol thanks we'll investigate this.

Can you clarify whether you were seeking on the timeline AFTER making changes or if you were stopping and restarting playback. As mentioned until you stop and restart playback it will not read the currently recorded automation. If its a BREVERB issue it would be up to Overloud to address it. However the version of BREVERB that Cakewalk had distributed is an older one so I'm not sure if they would update that.

I agree. It was a very good solution at the time and with some minimal decent driver support it would have been fully functional even today. Its a shame that Roland has this approach discontinuing stopping support for hardware devices prematurely.

Kurt, BREVERB has known bugs with its rendering of automation so most likely you are running into one of those. That is not an issue that can be solved from the Cakewalk side. Please retest with a different plugin and you should not see the same issue. Also something to note. In Cakewalk recorded automation is only applied when you stop playback so if you seek on the timeline to an earlier point where you had recorded automation, it will not render until you stop and restart playback. I don't think this is the issue you are encountering but I thought I would clarify it.

It's rarely useful to set track outputs directly to hardware outputs because now you lose control of the master mix. Good practice is to always output to a bus and or send to an aux bus.

That's how Russian roulette works with plugins that corrupt the heap it may work today and fail tomorrow

Has nothing to do with newer CPU's its how parallel processing of audio workloads is handled. But as I said I cannot comment until we have your project. If your project file plays ok on a different PC then you would need to troubleshoot at the PC level.

Where do you have these instances? In different tracks, stacked up or in buses. Best thing is to post the cwp file so others can see the layout of the plugins and the exact routing.

Its impossible to offer suggestions without knowing the setup of the project. Load is not distributed equally because of serial dependencies for audio processing. If you have one plugin in a track that takes a long time to process, it will become a bottleneck even though other tracks have low load, because the engine has to wait for the track to finish before it can be mixed. If you post your project file it may become more clear where the bottlenecks lie in your case.

It had nothing to do with Cakewalk not wanting to support it. Roland stopped supporting their hardware. If they still supported it we would have continued. We put a lot of effort into the VS700 and even extended our control surface SDK to do all sorts of editing stuff. This is all open source on Github if someone wants to utilize it for a different product.

Some drivers don’t terminate and hold the app captive. I’ve not seen this in many years but the some of the old Roland Drivers did this.

It only causes the behavior in cbb because it's corrupting the right chunk of memory to trigger the crash The app vanishing without a crash is almost surely caused by the plugin corrupting the heap. Heap corruption is like Russian roulette. It may or may not occur even from one version to another of the app because it is random. heap corruption issues are best diagnosed in a debugger using appverifier but even there it can be tricky to find.

You could say that you have an affinity for hard cores

How do you set this?

Can you zip and upload a version of the project that has the issue? You can pm me the link.

Which build are you running? This issue was fixed in the last update.

@ChristopherM Thanks I looked at the dump. Took awhile to uncompress a 32 GB file This is an unambiguous plugin issue. Cakewalk is simply doing an autosave and the plugin hangs when we try and retrieve the plugin state to save it. Cakewalk calls the getState function on the VST3 plugin and the plugin never returns from the call. This is something only the vendor can solve. ntdll.dll!RtlEnterCriticalSection() Unknown Non-user code. Symbols loaded. Chromaphone 3 Shared.bin!000000006b665367() Unknown Non-user code. Binary was not built with debug information. Chromaphone 3 Shared.bin!000000006b647f1a() Unknown Non-user code. Binary was not built with debug information. Chromaphone 3 Shared.bin!000000006b5ddfe9() Unknown Non-user code. Binary was not built with debug information. Chromaphone 3 Shared.bin!000000006b611ee7() Unknown Non-user code. Binary was not built with debug information. Chromaphone 3.vst3!00007ffb182656a7() Unknown Non-user code. Binary was not built with debug information. > Cakewalk.exe!CVST3PlugWrapper::GetChunk(bool isPreset, unsigned char * * pData=0x000000000014e690) Line 1974 C++ Symbols loaded. The plugin developers should be able to load up the dump file and find out why the plugin is deadlocking. Were you playing when autosave kicked in?

Hi @ChristopherM, Unfortunately your dump link is not available anymore. Can you resend it please.