Jump to content
Noel Borthwick

Diagnosing plug-in compatibility problems and crashes in Cakewalk

Recommended Posts

Some of the most common and complex problems that arise when using a DAW (digital audio workstation) are issues relating to plug-in compatibility.  At Cakewalk we take plug-in compatibility problems seriously and all reported issues are investigated. It is however impossible for us to test thousands of plug-ins in Cakewalk. While we follow best practices for VST compatibility, handling plug-in's can be complex since many vendor's do not test their plug-ins in all hosts, and there can be subtle or not so subtle (crash) behavior changes across plug-ins running in different host's. Before drawing conclusions on the cause of a plug-in related fault, its important to properly collect information that can assist with diagnostics.

If you encounter an issue with a plug-in here are some tips to diagnose it.

Identify the kind of problem. There are a few kinds of issues:

  • Compatibility issues. While this can be wide its important to try and isolate whether the problem appears within the plugin or the host. e.g do you notice the problem in the plug-in UI, does it occur with only certain presets, does the issue occur when loading the project or when exporting audio, etc.
  • Crashes. This is self explanatory but its critical to observe whether the crash report indicates that the crash in within the host program or within the plug-in DLL. The crash dialog will typically list the module that the crash occurs in in the title. If a crash occurs please save the Minidump for the crash since it is the only way for developers to diagnose the issue.
  • Hangs. In a few rare cases a plug-in can cause the host to hang. If a hang occurs you can still capture a dump file while the app is hangling, though it may be a lot larger.
  • Project specific problems. These are cases that result in unexpected behavior only with certain project files.

Diagnostics and action

If the plug-in crash is listed as happening within the plug-in DLL the first course of action is to contact the vendor of the plug-in. The reason for this is in many cases the the issue is caused by the plug-in running into an unexpected operation from the DAW that can only be fixed by the plug-in vendor. Every DAW is different and unless the plug-in has been specifically tested with a DAW there is a potential for unexpected bugs being discovered.

If the crash occurs in the host program (Cakewalk.exe is shown in the crash title) then one possibility is that the host ran into an unexpected condition. This should be reported to Cakewalk. It's important to note that not all crashes in the host are caused by the host. Plug-ins share the same memory space as the host program and as a result of buffer overwrites can corrupt memory, leading to random crashes or app shut-downs. 

In all problem cases the best way to report it is to provide the following details to all vendors concerned.

  • Write a detailed description of the problem
  • Include a zip file containing the project in which the problem occurs
  • Include all minidump's if the plug-in causes a crash. Please read this for more information on how to capture a minidump

In some cases Cakewalk will assist and work with the plug-in vendor to get a resolution to a problem. If you send a problem report to a third party vendor you may also refer them to contact us through our support channel at support@cakewalk.com should they have technical questions or require internal follow up with us.

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites

One thing I want to mention just in general is that there is often an unwillingness on the part of plugin manufacturers to dig into problems that involve Cakewalk, when we contact them directly.  I really much prefer to go directly to you/CbB and have you deal with them these days.

I've had Slate (and the various manufacturers they partner with), MeldaProductions, and JST all very flatly point the finger back at Cakewalk and refuse to dig further into issues, even without having been given much information.  It is what it is.  I'm not sure what y'all's standing with some of these manufacturers/publishers is, but it doesn't always seem to be good.

I don't like getting stuck in the middle of a three-way finger-pointing session (It's particularly frustrating when you guys can't figure something out or believe it's an issue on the plugin companies' end, but they all vehemently state that it's an issue on CbB's end), and ending up having to do all the diagnostics on my own and just throw it at everyone and hope someone can solve it. Particularly when it's not my job and I'm not being paid for my troubles.

As mentioned, there are some manufacturers that don't seem to hold Cakewalk (or the previous Sonar iterations) in high regard.  In fact, JST (a pretty big player in the scene now, especially among rock/metal engineers and musicians) has flat out recently told me to switch DAWs (not just for troubleshooting purposes, but permanently) and that they don't recommend Cakewalk.  (So at that point, I end up just getting frustrated/mad at everybody, which admittedly doesn't help.)

Lastly, there are a lot of instances where it's not easy to identify whether it's the plugin or the host, so often I push concerns to you guys by default (for the above reasons and more).  I realize coming to you guys with everything may be cumbersome, but it really is better and easier that way on our end...and I'm quite sure that less experienced/knowledgeable users don't know any better or have any idea what they're doing.  As CbB continues to be free and expand into new userbases, you're going to deal with that much more often.

 

Share this post


Link to post
Share on other sites

@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).

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

I wish I could recall the links to the posts and articles, but if you trust my credibility at all as a 58-year-old musician/business owner who spent most of the '90's in the software industry, in everything from startups to Adobe, I'll tell you that the situation with plug-in specifications and compatibility  is probably not what you imagine.

Even (especially) with the latest, VST3, if anyone thinks that Steinberg and other industry players (or even plug-in vendors) sat down and worked out the details of how VST's and DAW's should work together, then wrote out a spec, went over it checking for omissions and errors, and finally published it, then as errors and inconsistencies were uncovered by other companies and plug-in vendors, Steinberg was alerted and those changes were incorporated into revisions of the spec, then I must now inform  you that the Tooth Fairy and the Easter Bunny were actually just your parents leaving you money and candy.

It probably went more like:

Scene: Offices of Steinberg, 3 Months before Musikmesse 1996

Sales: "I think we can sell more copies of our new pluggy-inny Cubase if we let other people make plug-ins for it too."

Marketing: "Great idea! The new version with the plug-ins! Let's let everyone make plug-ins for it! We'll be legends, it'll be the new MIDI!"

Management: "Hey, people who chose coding and not technical writing as their career, give us the specification for the plug-ins so that other people can write them."

Engineering: "That's insane, we can barely make our own that don't crash the host, and we don't have it all written down in one place, it's in the form of comments in the code!"

Marketing: "Ha, ha,   you geeks have a great sense of humor. The spec must be ready for our presentation at Musikmesse. We're calling it VST for 'Virtual Studio Technology.' And don't worry, the outside vendors' plug-ins will all be certified by our QA process."

Engineering: "You're insane, Musikmesse is in 3 months and furthermore our QA staff can barely handle testing our own products with the resources they have."

Management: "Just have that spec ready for the presentation at Musikmesse. Even if you have to write it on a cocktail napkin and hand it to them, it will be ready."

A couple of years pass....

Scene: offices of an unidentified other DAW company

Other company's marketing: "Cubase got such a huge head start on us with that VST thing that it's become the friggin' standard, we have to make our host support VST's because people have these huge libraries of them. And plug-in houses don't want to code for DX."

Other company's management: "Hey, engineering, this is the VST spec from Steinberg, we will be showing off how our product can host every VST ever coded by anyone at Winter NAMM this year."

Other company's engineering: "This is a series of German swear words written on the back of a cocktail napkin from Steinberg's Musikmesse booth a couple of years ago and Winter NAMM  is in 2 months."

OCMgmt.: "Ha ha, you geeks have a great sense of humor. It's the full VST spec. Steinberg says so."

OCEng.: "Steinberg has no incentive for our host to be able to run VST's. It's the opposite. There's nothing in this about crash protection, memory management, preset management, default UI, installation location, sidechaining, UI scaling, they barely tell you how to get audio in and out. People will blame us when the things fail to load and/or bring our host down. We're at the mercy of Steinberg and the plug-in developers. It'll be a testing and support nightmare forever."

OCMgmt.: "This is the VST spec. We'll be showing off how we can host every VST on the market. I have faith in you."

(I made up the foregoing drama based on reading KVR and Wikipedia and my own experiences as a QA engineer testing a photo editor that was advertised as being  "compatible with Photoshop plug-ins." There is a financial incentive for the company who creates the spec to make it difficult for their competitors to use it. Cakewalk and  DP and Samplitude and FLStudio and Mixcraft get reps for being "buggy" and having compatibility problems, bingo, less competition for Cubase. Poor Mixcraft couldn't run a VST3 without crashing to save its life until the most recent version, 9, and Mixcraft is a stable program. Sampletank 3 never has been able to run for more than about 10 minutes without crashing in either CbB or MX. I'll bet it works a treat in Cubase.)

From reports, it didn't get any better with VST3. Maybe they added plugin-based sidechaining to the German swear words. From all I can gather, VST3 is the "New Coke" of plug-in formats, for those of you old enough to remember that marketing debacle/accidental success.

As for some plug-in vendors being dix, well, some of them are virtually one-person operations, and being good at coding does not necessarily, or even greater than 50% of the time, in my experience, go hand-in-hand with being good at dealing with other people. They're not all as personable as Noel! I am a one-person operation myself, and one of the reasons for that is I don't want other people telling me how to do things I feel passionate about. If you're even an  average coder, you can make a fortune working for any number of companies and not have to hassle with the things you have to deal with as a business owner, and have retirement and health benefits as well. So why have your own company?

Many engineers are, as they say these days "on the spectrum," and one of the things that goes along with that is difficulty in reading and conveying emotions. Being on the spectrum is often an advantage when it comes to the main work of coding, but a disadvantage when it comes to things like hashing things out with engineers at other companies. They can read to neurotypical people as rude and abrupt. They want to focus on the important thing (which would probably be the signal processing algorithm) and get annoyed by "peripheral" things like host compatibility.

Larger companies can hire people to act as a buffer between the coding talent and the rest of the world. I've had that role at a couple of companies. I felt like the "Jive Lady" in Airplane! "Stewardess, I speak geek." One-person operations don't have that luxury, so it's the world talking directly to the programming genius.

In the end, what works for ensuring compatibility is if the plug-in vendors feel it is worth their resources to help ensure it. Whenever possible, on forms or questionnaires, I let the vendors know I use Cakewalk. I put it in my sig on recording forums so people can see. I use Cakewalk and I buy plug-in licenses!

Edited by Starship Krupa
  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...