Dan Gonzalez [Cakewalk]
Thanks for the kind words and your professional insight on this matter. We are really trying to turn things around this product cycle. You guys have been a big help so far, and that is most definitely certain. That being said, it's hard for us to resolve an issue when it's presented outside of our internal support system.
I haven't seen this specific issue on my end in Marketing or Tech Support so could you provide me a way of reproducing this, or maybe some project files that exhibit this behavior? Maybe a support ticket or a problem report number? SONAR isn't the only culprit when it comes to project corruption. Plugins, Audio Files, and Downloaded MIDI files have caused major issues as well. I would love to work towards a solution for this if it is causing major stability concerns.
That's the thing, it's so intermittent. Every now and then a project will just get corrupt. If it's just a plugin, then usually the project will crash on opening, and loading in "safe mode" without the plugin will do the trick. I don't even consider those projects corrupt because they can be reopened. I'm talking about the "not a valid project file" or "could not open file" (I forget the exact wording) messages, where the project is gone for good and needs to be rebuilt manually.
Perhaps a separate thread would be a more appropriate place, but I'm sure if we were to ask hardcore Sonar users how many have had corrupt files, you're going to get a huge response rate. But intermittent bugs like these, by nature, are the hardest to diagnose because they seem impossible to reproduce. It doesn't mean there's not a problem, but it does mean that you could spend days trying to test for the error and never reproduce it.
That said, the problems are manifesting themselves in the real world and having a catastrophic impact on users in the rare cases when they do appear. If I were a Product Manager at Cakewalk, I'd have one or more developers spend a few days going through the save routine to make sure 1) there's no apparent bugs, 2) that there's not a better way to handle the save routine, and/or 3) that there's not some inherent flaw in the .CWP project format itself that couldn't be improved upon, or 4) just take a new look with today's knowledge and see if there's a strong case to be made to upgrade to a new project file format (perhaps an ASCII or XML based format).
It's a gut feeling based on what I've seen as an end-user, but my guess is 1) there's something in the save routine that makes it easy for projects to get corrupted, and 2) Sonar isn't checking to see that the save process was successful before committing the changes to disk and overwriting the previous version of the project file. I'd suggest building a check process in, and not overwriting any projects if the save was not successful (i.e. rollback to the last successful save). If there's an error on save, you'd want to show the user a "Save failed" message, and allow them some options to 1) try again, 2) select a new location to try and save the file again to (in case it's a disk issue), or 3) a cancel [and try again later] option. At least this way the corrupted project would never get committed to disk.
Also, I'm not sure if Sonar shuts down the audio engine during a save (I think no) but that's another thing you'd want to do if you're not already. It's possible that strange things could be happening to the system during saves as a result of the high CPU/RAM loads you can see while the project is running, and perhaps these could somehow be contributing to these errors.