THambrecht
 For example to set a simple marker. You have to insert a markertrack. Then you must click on an icon and then go into the markerwindow to name it !!!

Yes, and that text box for renaming the marker is nowhere close to the marker itself.  It is insane.  The obvious thing would be to clock on the marker, allowing the user to edit in place.  I find lots of example where you have to click something in one part of the screen, but then go to a distant part of the screen to actually change the parameter.  I guess one gets use to it, but it is very poor on the intuitive scale.
Another example is enabling and disabling the control room.  To enable it, you simply click the enable button within the CR window.  But if you want to disable it, you have to know (somehow) that you must hit F4 which brings up a very detailed dialog, and deep inside that dialog is a tiny button that disables the CR.  It just isn't a very sensible UI, IMHO.
Another example, Cubase automatically recognized my Scarlett 18i20, but only displayed the first two inputs.  It took me an hour of hunting to find the place where I could add the remaining paths, and it was nowhere near the place where you select the channel you want (which would have made sense), nor was it near the place where you can open the control panel for the audio interface.
When I started using StudioOne, everything seemed just where you would guess it to be.
 
Cubase is working reliably and is full function, so I am not terribly worried about it, but the level of inelegance is really a bit jolting, especially coming from a company that has such a high opinion of itself.

Resort Records
 

sharke
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 that's an accurate synopsis of the Cubase situation.  And, one hopes, a fresh, young team of enthusiastic developers will be more inclined to address our bug reports and feature requests.  Playing the Devil's Advocate, I suspect that those young developers will also target loop-based producers more so than traditional composers.  If Native Instruments is any indication, that's where the buzz (and money) is.  Remember when NI's product line consisted of just vintage keyboard emulations?  <sigh>  Now, it's all about the EDM.  Devices like the Roli Seaboard give me hope that support for full-featured keyboard controllers will make a comeback, but I doubt they'll ever fully support the old-school MIDI features of my trusty ol' Kurzweil MIDIBoard (ca. 1987).  That's the trade-off some of us face.
 
BTW, I would love it if somebody demos Studio One, Reaper, etc., and proves me wrong.  Maybe one of the young upstarts supports the full MIDI spec after all?  Hope springs eternal.

The thing is, I don't know of any EDM producers who just throw loops together. The whole "loop based" thing is a cliche, and you'll find that most EDM productions are extremely complicated affairs which utilize the power and features of a DAW to their max. You'll find extremely involved MIDI editing and routing, and every classic production technique (as well as a bunch of modern ones that are specific to electronic music). A lot of electronic producers spend months on a track, oftentimes drawing out hundreds of lanes of automation that would rival any symphonic production. Electronic music has always been on the cutting edge of audio technology, and many of these new production techniques are useful to all kinds of genres. That's why I believe that if Cakewalk had directed their efforts toward making Sonar more appealing to the EDM crowd, not only would we have had an even more awesome DAW with a lot of excellent and very useful features, but a larger user base as well. The young starry eyed EDM bedroom producer is driving a large part of today's DAW sales and tapping into that market is going to be good for the long term future of any DAW. 

I'm studying the Cubase 9.5 trial at the moment, and find myself really missing a lot of Sonar features.
I think the feature I miss the most is X-Ray . . . anyone know of an equivalent in Cubase ?
 
I also called up the Sonar Key commands in Cubase, which really helps in the DAW transition.
 
I really like the fact that Markers are done on a "marker track", which will surely help in a larger project to copy that track downwards.

I’m diving back into Cubase 9.5 Pro currently. That being said I’ve not dived deep enough for it to frustrate me in any way, yet. One thing I’d like to point out to those looking at old code as an issue. As some with a programming background wife over 30 years experience, old code overall was better written than today’s coders :).

A lot of sloppy programming today, oh it’s fine lots of resources. When you only initially had maybe 1mb of ram and 20mb hard drives, or floppy disks.. well you worked at a very different approach. One of reasons a lot of people have stuck with Cakewalk and Cubase is because overall, they’ve been powerful and consistent, quirks aside :).

Tony

sharke
The thing is, I don't know of any EDM producers who just throw loops together. The whole "loop based" thing is a cliche, and you'll find that most EDM productions are extremely complicated affairs which utilize the power and features of a DAW to their max. You'll find extremely involved MIDI editing and routing, and every classic production technique (as well as a bunch of modern ones that are specific to electronic music). A lot of electronic producers spend months on a track, oftentimes drawing out hundreds of lanes of automation that would rival any symphonic production. Electronic music has always been on the cutting edge of audio technology, and many of these new production techniques are useful to all kinds of genres. That's why I believe that if Cakewalk had directed their efforts toward making Sonar more appealing to the EDM crowd, not only would we have had an even more awesome DAW with a lot of excellent and very useful features, but a larger user base as well. The young starry eyed EDM bedroom producer is driving a large part of today's DAW sales and tapping into that market is going to be good for the long term future of any DAW. 

I meant no offense.  Clearly, we agree where a good chunk of the DAW market is and what drives innovation.  If I sound cynical, it's mostly that the current generation of keyboard controllers is so cheap when compared to those of yesteryear.  To this point, is anyone even making a keyboard controller with MIDI polyphonic aftertouch anymore?  If not, it suggests the market isn't interested in such nuanced performance.  Or, to be fair, maybe the bedroom market simply doesn't have the budget for those unavoidably pricey controllers.  Either way, it's a tight spot.
 

noynekker
I really like the fact that Markers are done on a "marker track", which will surely help in a larger project to copy that track downwards.

A useful tip for the Marker Track is to position it at the top and enable the Divide Track List option.  [It's the "/" icon in the upper right corner of the track screen.]  Then, stretch the upper split to just contain the Marker Track (and perhaps the Tempo and Signature Tracks, etc., if you also use those.)  It'll keep your markers from scrolling off the screen - more like Sonar.  Save this in your main project template.
 

Makzimia
A lot of sloppy programming today, oh it’s fine lots of resources. When you only initially had maybe 1mb of ram and 20mb hard drives, or floppy disks.. well you worked at a very different approach.

So true.  I wrote 8086/88 Assembly Language in the 80s.  If you didn't mind your resources and document the living crap out of everything, you were totally lost.  Object-oriented programming might be quicker but certainly doesn't demand as much from the programmer.
 
Then again, I tried my hand at OOP (ActionScript) a few years ago and just about fried my noggin'.  I'm just not wired that way.  Really difficult to trace if you're inspecting somebody else's code too.  So, I gotta give up some respect.
 

I agree that the standard of coding was probably a lot better back in the day. After all, they had to wring every last clock cycle out of a processor and not a single bit of memory went to waste. 
 
Coding is one thing, but what about software design - was that better back in the day as well? I don't think it was. The design of software is much more advanced now. Coding is just putting a design into practice. So regardless of how efficient some of that legacy code will be (and I have no doubt that it will contain routines of logic that couldn't possibly be coded any tighter), the fact remains that it was written to implement a software design that is now out of date. Who knows how much redundant code is in there, and how much of it is sneakily causing problems today in ways that would be a huge undertaking to track down and debug? Especially if it isn't documented sufficiently. 
 
And it's not just the source code either - won't that code also rely at least partly on legacy libraries that were stopped being developed or updated years ago? Who knows what kind of bugs are hidden in those.

I don't think it is a question of code quality per se.  Most of the programming in the early days was for business systems.  The computers were expensive and the programmers were somewhat rare. There emerged very strong disciplines for designing, building and deploying systems.  The goal was for the system to be exactly what the systems analysts had specified months or years earlier.
 
We are in a world of cheap computers, abundant tools, and plentiful people able to use the tools one way or another. But most of these people are not working on "core business systems", so to speak.  The systems they are building are considered more art than science in many cases; consequently the disciplines of the early days just aren't followed much anymore.
 
That, fundamentally is why today's systems are so vulnerable to hacks.  The priority was on producing the next cool feature, not on making sure there were no loopholes a hacker could exploit.  And that struggle continues today.
 
That doesn't mean today's coders are more or less capable.  The nature of the job has changed radically.

Speaking of code, and the issues faced by Cakewalk development with porting Sonar to the Mac platform, at least Cubase is cross platform already. 
 
The advantage to that is probably not having so much legacy code wrapped tightly around Windows libraries, and the dependencies that creates.  Platform independence could be a good thing in that regard! 

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.  There does seem to be a lot of problems in the past with this, but this web page describes exactly what worked for me.
 
http://www.codefn42.com/faq_routing_cubase.html
 
Or am I just missing something?  Why would I care about the MIDI Inserts (which are just Steinberg's I guess)?
 

sharke
Coding is one thing, but what about software design - was that better back in the day as well? I don't think it was. The design of software is much more advanced now.

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.
 

cparmerlee
I don't think it is a question of code quality per se.  Most of the programming in the early days was for business systems.  The computers were expensive and the programmers were somewhat rare. There emerged very strong disciplines for designing, building and deploying systems.  The goal was for the system to be exactly what the systems analysts had specified months or years earlier.

In the context of DAWs (or "sequencers"), early desktop hardware was really the bottleneck and forced programmers to be very efficient.  I remember writing video drivers in Assembly Language where the difference between using a SHR (Shift Right - equivalent to dividing by a factor of 2) and a DIV (Divide) - just a couple of processing cycles - could actually be seen on the monitor once the code block was being called thousands of times per second to refresh the pixels.  It was really pushing the limits of CGA video (to date myself).
 
Today, the hardware is so powerful, a couple of cycles won't be missed (though I'm sure the programmers at nVidea are pretty diligent re frame rates).  It doesn't guarantee sloppy programming but encourages it and, importantly, the effects are cumulative.  Compound it with time and modern object-oriented techniques, whereby new programmers have little need to understand the blocks they're building on top of, and you can imagine the potential for inefficient code.  And bugs.
 
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.