Anderton
FYI here's a great example of what I mean: http://forum.cakewalk.com/Solved-AAS-Ultra-Analog-Synths-crash-Platinum-m3201593.aspx#3201593
 
The user says that the AAS synths crash Platinum but they worked in previous versions. The issue was solved, and it was not related to Platinum.

As I see the resolution in that thread. Platinum was scanning and/or cataloging VSTs/VSTIs differently then X3 which caused the bad references. The question I pose is, was X3 doing it wrong all this time? Or is Platinum doing it wrong now? Obviously X3 had no problem parsing the multiple directories. Is Platinum parsing correctly now and revealing inconsistencies?
It's real easy in these forums to blame anything/everything other than Platinum. The ugly truth is, if it worked prior to Platinum, and Platinum changed it's VST scan process, and now the same installed VSTs crash the system, then the ramifications of Platinum's scan process changes were not tested thoroughly.
Now, should it be the user's responsibility to flush out those ramifications?
Only if Cakewalk makes us aware of the changes to VST scanning, and warns us to test all of our VSTs because some may not work properly. THEN, the responsibility would be on us. Otherwise, it IS Platinum's fault.

although i haven't anything to add from a technical POV, Jamesyoyo is far from a newbie and was a stalwart of the Songs forum back in the day when I used to frequent here a lot. You can rest assured he is using a pro set-up from a hardware perspective and will have done all the basic tests to try to find the culprit.
 
right, as you were...

a suggestion - I ran into similar "adventures" when I installed Platinum, crashes were frequent, and the audio engine refused to start in WDM or WASAPI modes.
 
I found two problems:
1) ASIO worked, but WDM and WASAPI were setting latency to the absolute minimum in audio settings. My machine is relatively new, but it ain't that fast. This seems to be default behavior in Platinum, I have verified that it does not happen in X3. Once I had this resolved I did go back to ASIO because it was still crashing too regularly.
2) Kontakt was out of date - I tend to avoid Kontakt updates since too many times they have caused problems, but this time it solved the problem. No more crashes.
 
I am comfortably running six instances of Kontakt with 14 to 16 instruments in each, and one stereo output for each in most cases (I do stack articulations where I can.) Projects can have upwards of 80 tracks without a hiccup.
 
The other thing I notice is that you are mixing 32 bit and 64 bit plugins. This has been a problem for me since X1, sometimes it works, sometimes it makes me crazy. For now my solution is to avoid 32 bit plug-ins like the plague. Which is unfortunate, since I still have a few I really like! I tried the demo for J-Bridge and it appears that some plug-ins, especially Virtual Instruments, seem to work better with one bridge and some work better with the other. When I have the time I will probably sort it out. Of course when I have the time they'll probably all be updated (that would be nice!)
 
Anyway, without knowing your specific configuration all I can do is tell you that I am runnign a pretty heavy template (for me) and it works well in Platinum.
 
My system was assembled last fall, and includes:
Intel i7-4790 (stock speed) on ASRock Z97 Extreme4 with 32GB of DDR3-1600 CL9 RAM, and NO VIDEO CARD! I splurged on a couple SSDs, and that has made a HUGE difference. And I am running Windows 8.1 Home Premium, I had hoped to use Win7, but 8 was significantly cheaper.
 
One other thought - I am evaluating Vienna Ensemble Pro as a host for Kontakt and other virtual instruments that I do not wish to have to load every time. It works well, even on a single machine. Three instances of Kontakt might not be enough to justify the purchase, but as you add more instruments you might want to take a look.
 
Good luck!
 

jatoth

Anderton
FYI here's a great example of what I mean: http://forum.cakewalk.com/Solved-AAS-Ultra-Analog-Synths-crash-Platinum-m3201593.aspx#3201593
 
The user says that the AAS synths crash Platinum but they worked in previous versions. The issue was solved, and it was not related to Platinum.

It's real easy in these forums to blame anything/everything other than Platinum.

 
It's important to differentiate between a reproducible bug that can be reliably traced back to a flaw within Platinum, and a general statement that "Platinum crashes all the time." It's clear Platinum doesn't crash all the time, or Jamesyoyo's thread would have a lot more company and people would be piling on here detailing their "crashing all the time" problems. Previous threads that did complain about SONAR "crashing all the time" were generally resolved through troubleshooting that uncovered either pilot error or hardware/software interaction problems.
 

The ugly truth is, if it worked prior to Platinum, and Platinum changed it's VST scan process, and now the same installed VSTs crash the system, then the ramifications of Platinum's scan process changes were not tested thoroughly.

No. It's unreasonable to expect Cakewalk to test Platinum with a wide variety of bad installations to see what happens. The source of the problem wasn't SONAR's scanning process, the problem was multiple installations of the same plug-in in multiple folders. That's wrong from the gitgo. The user was lucky that it worked okay in X3 but the fact is the scanning process continues to be improved in several ways (e.g., from what I understand it now works in Vista, which it didn't in X3). If the scanning process is more rigorous, it's reasonable that it would be less tolerant of user-created problems. 
 

Now, should it be the user's responsibility to flush out those ramifications?
Only if Cakewalk makes us aware of the changes to VST scanning, and warns us to test all of our VSTs because some may not work properly.

 
 
It's up to the user, not Cakewalk, to install plug-ins correctly; when the plug-in WAS installed correctly, the "problem" was solved. I wouldn't expect Cakewalk to add a disclaimer that says "If you've installed something incorrectly, it's more likely that SONAR will catch it now because the scanning process is more rigorous." Cakewalk wouldn't know that was the case unless their QA team installed something incorrectly on purpose, tested it, happened to choose the right "wrong" installation, didn't reset/re-scan, and then found out that the incorrect installation caused a particular problem.  
 
Different programs scan differently, and scan routines change over time. Anyone who has used multiple DAWs will tell you that some programs will install plug-ins that other programs won't install and vice-versa. 
 

Just wanted to drop a note that I too am having the same issues as James (minus the disappearing audio driver) where as a project increases in track count and complexity, stability and TV response degrades until it becomes unusable. My last project the stability degraded to a point where simply saving the project would crash. The project file itself became corrupted, as it would crash x3 as well. I was able to save myself by loading an older copy in x3. On a new project, where i have jamstix, ad2, and ezkeys set up to work out my basic arrangement, I've started to experiance the same issues. Rendering down all the audio tracks and removing the vstis didnot improve the situation. I've since started from scratch with the same setup in x3. No issues there.

I was one of the lucky who get to pick up Platinum and early, and I've been taking my time in isolating this issue, since X3 runs fine.

Again, this is just to let folks know that there is at least one other person who has the same symptoms in Platinum. Though I have a completely different project setup and different interface. I plan on working with support on my issue as soon as I get a few days off so I can be at my daw while on the phone. I suggest to James to do the same if he can.

I've had a number of problems recently, too.   Specifically with "paste", as mentioned in the OP, and with medium sized projects that are growing in midi clip numbers  Haven't had crashes, but have had several "freezes" ("Sonar is not responding ....).    And, just today, one freeze that was captured, unfortunately, in the autosave backup ... not pretty.    Using Platinum, latest version.  

And moderators, especially you volunteers:  PLEASE don't try so hard to minimize every problem report.   Yes, some are exaggerated, but most of us wouldn't bother if it weren't real.
 

williamcopper
And moderators, especially you volunteers:  PLEASE don't try so hard to minimize every problem report.   Yes, some are exaggerated, but most of us wouldn't bother if it weren't real.

I guess that sometimes there is at least the impression that a problem report is being marginalized, but I think in this case, and most others, folks are simply trying to get more information - so that they might offer suggestions - and attempting to calm the waters a bit.

If a problem is directly related to a Sonar software bug then that's one thing. But DAWs are complex beasts, and if you start with the assumption that it is a Sonar problem, and it isn't a Sonar problem, then you spend valuable time chasing the wrong path.

Anderton

 
No. It's unreasonable to expect Cakewalk to test Platinum with a wide variety of bad installations to see what happens. The source of the problem wasn't SONAR's scanning process, the problem was multiple installations of the same plug-in in multiple folders. That's wrong from the gitgo. The user was lucky that it worked okay in X3 but the fact is the scanning process continues to be improved in several ways (e.g., from what I understand it now works in Vista, which it didn't in X3). If the scanning process is more rigorous, it's reasonable that it would be less tolerant of user-created problems. 
 

 
So you are saying, X3 did it wrong, but it worked. Platinum does it right, and therefore it crashes.
X3 was obviously more forgiving. Was it a development decision to make Platinum less forgiving? Or did the bakers just miss the reasons X3 was coded to be more forgiving?
 
I don't expect Cakewalk to "test" bad installations. But I do expect the programmers to understand the ramifications of their changes.
 
Craig, I have been programming since 1981. Started prior to even DOS. Commercially coded in DOS, Win 3, 95, 98, ME, XP, Vista, and 7. Coded for networks, security, databases, UIs, and graphics. So I am not talking out of my you know what.
 
The primary problem I am seeing at Cakewalk, is, marketing is driving development. I don't actually fault the programmers as they are under time pressures that are unreasonable. Although, I do think they get a little sloppy pushing out releases. I would rather see much more time and resources spent on fixes instead of features. But I know marketing would not stand for it, and the ADHD crowd would get bored.
 
It is apparent, our development/programming/support styles are worlds apart, and we probably won't agree on the fault for the instability. But, in my 34+ years of programming, when I released a fix or a new version and the customer's system crashed, I ALWAYS assumed it was MY fault (so did the customer).
I did something to the code that no longer worked. Period.

williamcopper
I've had a number of problems recently, too.   Specifically with "paste", as mentioned in the OP, and with medium sized projects that are growing in midi clip numbers  Haven't had crashes, but have had several "freezes" ("Sonar is not responding ....).    And, just today, one freeze that was captured, unfortunately, in the autosave backup ... not pretty.    Using Platinum, latest version.  

I'm sorry to contribute to the further hijacking of this thread, but...
 
You really need to document this claim about "too many MIDI clips" in away that makes it reproducible by others. I find no references to "too many MIDI clips" anywhere in the forum history other than your recent posts, except for one several years ago that actually turned out to be "too many soft synths " for the chosen buffer size and available processing power.
 
I've made the effort to experiment with some fairly large MIDI projects, destructively splitting every track at measures so that there are hundreds of clips in the project, and I can't reproduce any problems. I've even split some of those tracks up further, giving every note number its own take lane (!), and still didn't see a problem.
 
Whatever problems you might be experiencing in large MIDI/soft synth projects, I think the MIDI clip count is a red herring. I would sooner suspect interoperability problems with Kontakt which has previously been implicated in a number of instability issues and assorted unexpected behavior.
 
And regarding your comment about minimizing problem reports, given the historically high rate of problem reports (both formal and informal) turning out not to be SONAR bugs, it only makes sense to ask users to come up with reproducible steps for replicating a problem, both to ensure it's not a simple procedural problem or interoperability issue with some third-party software/hardware, and to give the Bakers half a chance of troubleshooting and fixing it.