Noel Borthwick

Great to hear that we were able to help resolve this issue for you. A systematic process of elimination is the best remedy when you have system specific issues like this because it can be easy to draw the wrong conclusions. If you could contact the plugin vendors you were in touch with who claimed it was a Cakewalk bug that would be great, so that they don't continue to spread misinformation to other users We'll also try and put together a KB of known third party problems and troubleshooting techniques that might assist others. Now go make some music

For the record this is a 100% third party problem that affects other DAW's on affected systems, not just Cakewalk. Future note to other plugin developers who are quick to blame Cakewalk @AxlBrutality were you able to verify that your Cakewalk LP plugins no longer need the ini file setting to override open GL after you uninstalled Nahimic?

Most ASIO devices will auto switch to the sample rate requested by the host when you load the project, but some require you to explicitly change it via the ASIO driver control panel or via a physical switch on the audio interface. Also note that changing the value in preferences only changes the sample rate for NEW projects. i.e if you load an existing project that is already locked to a certain sample rate, changing the default sample rate value will only affect NEW projects not the currently loaded one.

That's definitely a relevant observation thanks. It's likely what is triggering opengl to do whatever it's doing to hang the Cakewalk UI.

If all you want to do is interactively slow down the clip just slip stretch the end of the clip till it's as slow as you want. Hold down the CTRL key and then drag the right edge of the clip ahead of time to lengthen the clip.

We'll investigate this - thanks.

The message typically means that the sample rate of the project file is not supported by your audio interface. Are you running ASIO or WASAPI mode? The current project sample rate is displayed under the now time. It may be as simple as switching your audio device to that sample rate in case the interface has to be externally switched.

Hi @Billy Buck you have 20 msec because you installed the original .11 release. New users going to this version will have it properly reset to 200. The reason for this flux is in all our testing 20 seemed sufficient. However a few user systems had dropped notes. There is a big internal change from SONAR (which had a bug with the MIDI buffer size interpretation) which is why we adjusted the value. In the new build for most people it should be fine at 20 or 50 but I've bumped it to 200 to cover more corner cases. Sorry for the flux. I may change the final release to reset it to 200 on first run once more.

@Dr. Failure Audio slowdown and distortion while playing is a symtom of overload where audio cannot be processed in time for the driver. You can alleviate this by raising the audio latency. Which driver mode are you using? WASAPI shared mode is the best for devices like headsets but it has an upper limit of 10 msec which might be insufficient. Try using WASAPI exclusive mode and set the audio latency slider to something like 30 msec. Of course this will cause latency so you won't be able to monitor without delay. Please get the latest hotfix since it has some improvements with WASAPI when using different input and output devices.

It may be cheaper and a lot quicker to just try a new video card. Just buy a current gen card and try it - if it doesnt work you can possibly return it.

FWIW here is a post from one of our developers on the JUCE forum regarding this very issue. It hasn't been addressed since 2017 Another thread discussing this issue. Have you experimented with upgrading to a newer/different graphics card? This could very well resolve the issue.

I think you are reading too much into my text. I changed the wording to look more neutral if it helps I was trying to explain why issues like this can take time to solve when the problem isn't part of the actual DAW code. If it was we would have fixed it back in 2017 when we had an issue with our own LP plugins wouldn't we? It isn't a question of who's fault it is. Its system interactions between multiple third party components. In all these years we have only had a tiny number of customers who had the issue with the LP plugins and we provided a fix to not use opengl for those who did. Apparently some plugin vendors have done the same and others have not. When you talk to support at a company, the reps are typically not developers and the best troubleshooting they can do is run "black box" comparisons like testing in other hosts. Until an actual developer looks into the issue in detail there is no way to conclusively find a real solution. However most plugin developers are DSP engineers and opengl problems are likely not an issue that they may have expertise with. Couple it with the fact that many only work on Mac's (JUCE abstracts all the cross platform dependencies away) and its even harder for them to investigate deeply. >>Do you have any idea if JUCE would be working on a fix. No but its unlikely from what I've seen. They do not prioritize GUI issues and this is surely at the bottom of the pile since it impacts only a tiny number of users. @Ben Staton is going to try and look into it some more when he gets some cycles. What makes it harder for us is that we don't have any systems that exhibit this problem. I have NVidia machines and they all run the slate plugins as well as our LP's fine without any tweaks. Given the nature of this issue we can't promise any results but well try.

@zaquria when you don't need the ability to switch view layouts on a per project basis, workspaces are a much better solution and part of the reason why we built the feature. You can create specific workspaces that apply to ALL projects and switch to a certain workflow specific layout at any time. Of course you can still save per project screen layouts. If the current workspace is set to "none", when you open a project it will open exactly the way it was saved. It may take a little experimentation to customize workspaces to your taste but once you do that its a simple and powerful way to quickly dial in a view of the application that is suitable to the task at hand. Its a lot more powerful than screensets since its a superset of that functionality.

The issue has to do with how some specific OpenGL versions interact with the Video driver. Its not a host problem as such. Cakewalk itself doesn't use OpenGL but we use normal Windows API's, GDI+ and some Direct 2D to talk to the graphics devices. Nothing special. The LP plugins are built using JUCE which does use opengl. As far as we know the Melda plugins and other plugins that have the opengl issues are also built using JUCE. The JUCE dev's were notified of this back in 2017 and their response was that it was related to some interaction with the version of opengl higher than 2.1. Under this scenario the plugins that use OpenGL end up hanging with some video drivers when initializing opengl. IOW The hang itself doesn't originate from the app itself but in response to the plugin initializing opengl. This is what complicates the issue and makes it difficult for us to address at the host level. The fact that it doesn't hang in another app isn't particularly useful other than indicating that problem won't manifest there because of some other dependencies. Our workaround for the LP plugins was to have a setting that skips opengl altogether. This was done back in 2017 and the plugins have not been updated since then. We'll continue to investigate this to see if there is some workaround that can be handled at the app level.

2019.11 Hotfix Release Candidate (HFRC) installer now available! Thank you to everyone who provided feedback on the official 2019.11 release! This hotfix addresses all problems reported and reproduced since then based on field reports and user feedback. We have also made some improvements to WASAPI mode and fixed some long standing issues to improve device compatibility. Please continue to report any issues in the 2019.11 feedback thread. We plan to officially release this hotfix very soon, so any early testing would be appreciated. Note: The HFRC installer will either update the original 2019.11 release or the prior early access HFEA1 build 59. Please choose the appropriate installer based on the version you are running. Download Hotfix RC for original 2019.11 release Download Hotfix RC for prior early access HFEA1 build 59 What's New WASAPI Shared mode now supports all audio sample rates. This is independent of an audio device's supported native sample rates. All other sample rates will be sample rate converted to the native format. This provides a convenient mechanism to to open even a 384K project on a laptop and play it through its onboard audio device. Full Screen mode now persists globally instead of per project i.e. you can only toggle Full Screen mode via the Full Screen mode button or by pressing F11. Closing or opening projects or switching workspaces will no longer exit Full Screen mode. Track icons are now shown by default in the Console view when using the Basic and Record workspaces. Note: Factory workspaces are always overwritten when installing a new release. If you need to customize a factory workspace, please save your workspace as a new name to prevent it from getting overwritten by a future Cakewalk release. MIDI playback buffer size default value has been raised to 200 milliseconds to accommodate system timing variations and prevent dropped notes on some systems. If you ran the prior .11 release you will have to manually change it to 200 (if you are experiencing dropped notes or noticeable dropouts) Fixes Glitchy audio playback with WASAPI on some devices - particularly with onboard audio since updating to 2019.11 Crash if an ASIO device was disconnected while in use by the application Glitches in WASAPI audio playback since updating to 2019.11 Application could freeze when recording or playing back MIDI under certain buffer settings Onboarding dialog opens unexpectedly after updating to 2019.11 Intermittent Control Bar Transport module progress bar related crash Recording in WASAPI and WDM could record audio at wrong speed depending on selected order of devices in Preferences dialog box Latency slider value was not displayed in WASAPI Shared mode Closing the application with toast notification showing could cause a crash Help > Get Started menu option missing from localized versions of Cakewalk Switching driver modes crashes during playback Melodyne opens without blobs focused in 2019.11 Audio devices fail to open in WASAPI Shared mode at non default sample rates

@Mcu pro I replied to your original thread. Can you post a screenshot or list the dropout code in the message that you get. Have you also tried increasing the MIDI playback buffer size in Preferences | MIDI | Playback and recording. Set it to 100 or 200 and see if it improves. If you are crashing we'll need to see a minidump.

@Mcu pro A few things to check: which version of Cakewalk are you using? Are you using the Apollo ASIO driver? Check that Cakewalk is running in ASIO mode in preferences What audio buffer size are you running at? Are you getting a dropout message? If so please list the dropout code that appears in the message Are you getting a crash or hang? If so please capture a dump file and send me a link to it. This will help diagnose it.

That screenshot is incorrect. The audio driver mode needs to be selected from the audio section instead. If you want other apps to play audio the best mode to use is WASAPI shared because behind the scenes Windows mixes other applications audio streams. Most devices should work with WASAPI shared. Ironically some pro audio interfaces perform poorly in WASAPI mode - likely because vendors only test in ASIO mode.

@AxlBrutality I fully understand this. We have excellent relationships with many plugin vendors. Waves, NI, Celemony, Arturia and Steinberg are some big guys who come to mind but there have been numerous others who are extremely responsive when there are compatibility issues. On the other hand others make assumptions without doing the due diligence testing and debugging. Doing a test that compares a plugin in host A and inferring that host B is to blame because it doesn't work there is flawed logic. Software is far more complex than that and most competent developers would never make that assumption. Just in the 09 release I communicated with Steinberg about verified bugs in plugins state management that we have to work around. This is an ongoing problem and not something we can solve directly since none of us have any control over third party vendor timelines and policies. I can say with 100% certainty that when a vendor reports a specific compatibility issue to us we bump that to the highest priority to solve as soon as we can and work with them directly to get to the problem. The bottom line is if a plugin vendor asks you to switch DAW's without supplying evidence that it is actually a DAW issue, its really your call to decide the value proposition of whether you would rather stick with that developer or abandon your DAW. One root issue I have seen is that some plugin developers do not test on Windows systems and can be quick to dismiss plugin bugs as being host specific without actual verification. Some others regurgitate obsolete out of date information. Yes in the past we had compatibility issues but the vast majority of plugin issues have been resolved over the years. Our VST3 implementation is second to none (even by Steinberg's admission).

@Colin Nicholls Strange. is this a MIDI or audio project? When it goes silent, do you see meter activity on the Main outs in the console?

Its wired to Melodyne always

Yes ARA 2 is aware of selection. There was a change that was deselecting the clip so that made the blobs not visible on execution of the command. If you select something else and then reselect the clip the blobs would be visible again.

@Matthew SorrelsDoes it work for you with CTRL-M?

@Matthew Sorrels we were able to repro it when you create a region effect from the menu. The shortcut CTRL-M still apparently worked ok. We think we have identified the cause and fixed it. It will be in the hotfix that we release soon.

@Matthew Sorrels are you sure that this is new to the .11 release? No changes in that area that I know of that could have impacted that.