msorrels
While I've only had Cubase Pro 9.5 now for about a week, I'm pretty sure MIDI VST's work, since I've got Kirnu Cream feeding MIDI to AAS Player without too much trouble.

Kirnu Cream appears to be a VSTi - not a true MIDI VST.  If it were a MIDI VST, I don't believe it would load properly into a Cubase Instrument Track.  But I could be wrong!

Resort Records
It supports the argument that newer applications will be leaner and more reliable (if perhaps lacking in legacy features), if only because the company is on its first generation of programmers and everyone knows what's what from the ground up.

I don't know.  What I was getting at is that the whole approach to applications is different.  DAWs and other "pioneering" apps are mostly written by hackers.  I don't mean that in a negative way, and I don't mean the criminal context of that term.
 
I mean hacker, as opposed to a person coding to a well defined spec.  Hackers hack away at a problem and keep improving things until they have something useful.  And even with today's powerful cores, some of these audio algorithms must be extremely tight.  It is amazing to me that it is possible to have 50 or 100 complex plug-ins running with the system still running only 20% busy.  I am amazed at what Melodyne can do.  I am amazed every time I see the Izotope dynamic EQ or a good noise reduction algorithm.  Somebody worked very hard on those algorithms.  There certainly may be plenty of examples of sloppiness, but there is no shortage of examples of very tight code.

Resort Records
 
It supports the argument that newer applications will be leaner and more reliable (if perhaps lacking in legacy features), if only because the company is on its first generation of programmers and everyone knows what's what from the ground up.

I'll buy that argument.  I keep thinking of popular Sonar feature requests that Cakewalk was dragging their feet on implementing.  Probably too much legacy code that nobody today knows anything about, and the risk involved of breaking something with a change.
 
They killed Project5 for various reasons, but I believe one was that the the original programmer had left the company.  That should have been updated to multi-thread and released as 64-bit.

Resort Records
 
I agree.  If you look at phone apps, for example, UIs have gotten so polished and efficient.  And standardized - everyone knows how to operate most any phone app without any real education.  With a few exceptions, you know what the app is supposed to do, the controls get right to the point, and it works.  Well, usually. 
 
That's why Cubase drives me nuts.  Generally, the engine is powerful.  Now, if they would just adhere to modern UI design standards, rather than going maverick at every opportunity, the program would be so much more accessible.  [For example, they could start by moving most of the Devices menu under Preferences, where those things belong.]  As others have said, it's like they're trying to trip us up or something.

When I started out with computers, the only UIs were keyboard and teletype printer, no CRTs yet!  And we punched programs into paper cards or tape.
 
Everybody knew what a carriage return key was used for, as well as an alphanumeric keyboard.  The typewriter metaphor was familiar since the first commercial typewriters were introduced in 1874.
 
Things have certainly changed for the better, and I would never go back, LOL!!!
 
The success of the Apple and Android devices really does say a lot about the effectiveness of UI design, beyond the fact that they are portable pocket computers that can go anywhere.
 
Regarding DAWs specifically, most could use some improved focus on UI design.  Having a universal design for a DAW GUI would probably be impossible to achieve, unless the leading DAW on the market was designed by an open source standards team, that had the backing of a large company to really study the problem. 
 
Then maybe everyone else would choose to copy them, like the mobile device market.  But since the DAW market is so much smaller than the mobile device market, it's probably just a dream! 

I spent the better part of 6 hours moving my first project from Sonar plat to Cubase 9.5 pro. I exported the midi and essentially created a Cubase template with all my base instruments. Did all routing, color coding etc and google'd extensively. It's probably in Cubase, but I miss the "Smart" mode in the PRV with all the elegant CTRL+SHIFT/ALT/ click/drag options.
 
Two interesting observations: Cubase runs the same project with only 2/3's of the memory and far less CPU load. It also sounds clearer in Cubase. Not sure why, as I use no native Cubase or Cakewalk effects (it's all Izotope).
I will audit the memory usage again today and maybe I forgot to move something or load an unused articulation.
 
BTW, the project also sounded better without Izotope Neutron2 "all over the place", so it was an interesting day.
 
I will eventually consider Cubase an upgrade, is my guess.

abacab

Resort Records
 
It supports the argument that newer applications will be leaner and more reliable (if perhaps lacking in legacy features), if only because the company is on its first generation of programmers and everyone knows what's what from the ground up.

I'll buy that argument.  I keep thinking of popular Sonar feature requests that Cakewalk was dragging their feet on implementing.  Probably too much legacy code that nobody today knows anything about, and the risk involved of breaking something with a change.
 
They killed Project5 for various reasons, but I believe one was that the the original programmer had left the company.  That should have been updated to multi-thread and released as 64-bit.

I remember a few years ago reporting a bug on the forum in which Sonar's arpeggiator could not have its on/off switch controlled by automation unless the track in question was in focus, and another similar issue in which I think you could not automate the on/off switch of a ProChannel module unless that particular ProChannel was open in the console. Seemed like pretty straightforward bugs which (to the layperson) would be a relatively easy fix. But someone from Cakewalk chimed into the thread to say that they were aware of the problem but that they had no intention of fixing it, because to do so would break other areas of the problem. That to me was a pretty obvious case of legacy code/structure presenting itself as an obstacle to new development. If Sonar had been a young program with a fresh code base, you cannot imagine bugs like this being so impenetrable that the developers give up on them. I can imagine the Bakers having to deal with legacy code that was, after all, not designed with Sonar 2017 in mind, and was not necessarily the ideal kind of code that you'd write if you wanted your app to remain 100% future proof. This probably leads to all kind of workarounds, hacks and Band Aids in the code to make newer stuff play nice with older stuff. Maybe they had to repackage old code in wrappers to make it comply with Sonar's modern architecture. Maybe the code has dependencies on old, long forgotten libraries which went out of development years ago and which have bugs of their own. 
 
While there are probably parts of that code that are 100% rock solid and could not be improved upon if you tried (i.e. code that dealt with pure logic rather than GUI's or hardware or DSP), I should imagine that there are many legacy parts of any 30 year old app that could benefit from a complete rewrite. But that's where development budgets come in - perhaps it would have been just too expensive to "renovate" Sonar to that degree. 

sharke

tenfoot
Thanks for the great summary David! 
 
One of my concerns with Cubase is that it may suffer the same legacy of decades of layered code, updates and convoluted behaviour that plagued Sonar. I was used to its quirks and they were never be enough to drive me away. Now that I have to change, I really want to strike that balance between deep features and young and snappy. Any thoughts on this would be appreciated!

This is a concern of mine as well as I select a new DAW. Sonar had a ton of really hard to pin down bugs and quirks that I'm convinced were caused by legacy code and new code not getting along.  Legacy code wasn't necessarily written to be future proof, and I can't imagine developers enjoy reverse engineering code that perhaps isn't documented sufficiently. Apart from anything it's a drain on resources. 
 
Many of Sonar's oddities were impossible to reproduce with a recipe, which meant that unless the Bakers had an "a-ha!" moment of enlightenment, the chances of them being fixed were small. I must have brought up dozens of issues on the beta forum that never ended up as bug reports because they could not be reproduced at will. Sometimes I would attach projects along with a bug report, in the hope that the project would demonstrate the behavior even if I couldn't come up with the steps. Oftentimes I would hear back "we're not seeing this at our end," which suggests that some bugs were peculiar to specific machines or installations - even harder to track down. A couple of times I heard "we're aware of this but we're not going to fix it because to do so would break another part of the program" (in discussions in the public forum no less) which again suggests a problem caused by legacy code that would have taken too long to get to the bottom of - the Bakers obviously had to manage their project resources frugally and taking the engine apart to find something that was more of an annoyance than a showstopper was probably deemed to be an inefficient use of their budget. So, many of the annoyances stayed across versions without any hope of a fix. 
 
An example of this is that 3 years ago I reported a problem with automation envelopes becoming misaligned when looping a section. A horrible problem which means that you cannot always rely on your automation playing accurately when a loop is enabled. The bug was never fixed, and looping in general has a ton of related problems in Sonar. I suspect that the looping code is an example of the core legacy code which made problems so hard to pin down. Some of the program probably needed a rewrite but they didn't have the budget to do this alongside the pressure to add new features and the like. 
 
So one of my main attractions with switching DAW's is to start with a fresh young program that has a modern, coherent code base. That's why I'm looking at Bitwig and S1. I know that Cubase is probably one of the most powerful, feature rich DAWs in comparison with Sonar, but when I think about it I didn't use half of Sonar's features. Do I really want a bunch of functionality that I'll rarely need, at the expense of potentially dealing with a set of hard to fix, hard-baked bugs in ancient code? 

I think it's unfair to compare Sonar to Cubase. Cubase had been completely re-written for SX1 in 2002. Then that code was mostly re-written when Cubase 4 was released in 2006. That cycle was completed in Cubase 7, in 2012. The original Cubase re-design allowed for modular updating of the code. That's why Nuendo and Cubase have the same audio core, but different external functionality. Some of the code in Sonar Platinum came all the way from the first version of Cakewalk. Having used both programs extensively, Cubase is completely stable, and has far less quirks than Sonar. Their development team has done a great job of squashing bugs in the last few versions. Even S1 is having a problem with automation that they haven't been able to solve in several updates. 

THambrecht
Our problem was to find a DAW that has all audio features like SONAR or better, becaue we have to work with thousends of tapes and have them to restore. Therefore we bought now Cubase 9.5.

Have you by any chance looked at Pyramix from Merging Technologies?
I am not familiar with it but believe it is highly reliable. Further I am not sure about the hardware requirements for using the software...... you mentioned you are in need to change PC's as well ?
 
http://www.merging.com/products/pyramix/key-features

I started the 30 day demo of Cubase 9.5 (Don't even get me started on how stupid the e-licenser thing is. HATE IT!!!!!!!!!). I decided that if I do switch Cubase is the one I'll go to because I primarily build compositions in MIDI and then output audio tracks from my sound modules and VSTs. 
 
I find the interface absolutely inscrutable. For example, if took me forever to figure out how to get my audio interface to be an output (instead of the stupid generic ASIO driver thing). When you have to look up online help for something as simple as this, trouble is a'comin'. 
 
But.....I'm willing to give it a closer look. One question i had based on the original post is he said the legacy MID VST programs won't work with Cubase? Does that mean that all of this many VST plugins I have, from Dimension Pro to Lounge Lizard to Arturia Keyboard V, won't work in a MIDI situation with Cubase? That would be a total deal-killer. 
 
 

It's actually coming across as quite interesting how people are finding the complexities of other DAWs now that (in a sense), we have to. And yet, many (myself included), are somewhat blinded to how deep Sonar actually is/and can be. Coming from a 2-track tape-recorder in the 1960s to Sonar approx 2011. The sheer depth (now 2017), of what can be achieved inside a computer is mind-boggling. I honestly can't believe that Sonar will die. There are too many smart cookies out there who know they can make money (the primary objective), to let a solid customer base, as is Cakewalk, totally go to the wall. As others have said much more eloquently than me, I wouldn't rush anywhere just now, esp if Splat etc is solid.