Noel Borthwick

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.

Definitely not for wasapi shared. It's capped at 10 msec always. Wasapi exclusive can both go higher than 10 and lower. Maybe you were using that?

Hi @Krecikdwamiljony thanks for the report. in wasapi shared mode unless you have a win10 driver that supports lower latency the latency is fixed at 10 msec. Since you are running win 7 that would be the expected result here. I think there is a ui issue with the slider being grayed out which we'll look at. Thanks!

Hi @Jean I understand that any change takes time getting used to. The problem is that RTZ in any other application means what it says Return To ZERO. The behavior of jumping to a loop start is very unexpected for most new users to the program. We plan to have a new control bar module with better jump points in the future which should allow for easily navigating around various hotspots in the project. In the interim if you prefer using the mouse you can create a new button in the control bar and assign it to the "Rewind to Landmarks" which is equivalent to the W key.

Shouldn't be related to this version. However can you send us the minidump file for the crash please? See this article for more details.

Did you explicitly run the getting started option or was this the first time you installed cakewalk? Getting started runs for first time installs.

Which version of Cakewalk are you running? Is it this month's release or earlier. Have you tried raising your audio latency?

Hi is this a MIDI project or are you seeing this on audio tracks as well? Are you running the latest release from this month? Im not sure what you mean by fading out. Are you getting dropouts, missed notes or is it that you hear a gradual fade.

Activation and updates have always been a requirement. Its also mentioned again in this months release notes. If you had been regularly updating you would have got an update that changed the application to warn you well before it required re-activation.The software doesn't "lock up". It will give advance notice when reactivation is required. It can be activated without updating the Cakewalk application itself, by using BandLab assistant's reactivate feature. It's recommended to update as well since there are often important changes and bug fixes. The process is even more streamlined as of this version. The only requirement for this free software is that it is updated periodically. Its a small price to pay for a completely free professional DAW. One of the reasons why we require periodic updates is that we continue to improve the application and cannot support multiple versions of the application in the field. Only the most current version is supported. Independent of Cakewalk itself, the BandLab assistant app also needs to be periodically updated. Its a web based application and its normal for those to require updates whenever the web back end is changed otherwise it would stop working. We live in a connected world today and completely offline use is less prevalent with most modern applications. Despite some of the pessimistic views on this, there are many ways in which this benefits customers. Users get responsive updates and we as a company get important feedback about how the application is being used, allowing us to improve the application for all.

There is a hotfix that was posted yesterday for an issue with WASAPI. Please keep comments about the 2019.11 release in the main feedback thread here.

@Ondrej HurbanicIt could potentially be Windows 7 specific. Can you check what the MIDI playback buffer size is set to in "preferences | MIDI | Playback and recording | Prepare using ..." Try raising that to 50 or 100 and see if it helps. Is it just the time display that is unsteady or is playback also affected?