Cubendo 14

What you’re citing is in relation to the codebase. Steinberg is possibly using a older system that requires that kind of menu bar. PyCharm and others are using a more modern system.

This will not be an easy thing for Steinberg to address. They are in a difficult spot because their codebase is likely very old.

I agree with you that a DAW should have a modern experience like PyCharm and JetBrains but achieving that will be hard unless we agree to a subscription model for Steinberg (of which I am in favor of).

I am not against it, but there must be two options: subscribe or purchase
Or increasing the price of the program. I am also not against it
But if there are radical developments and not waiting for a year each time to bring a simple update
I believe that it is incorrect to create two separate programs. The two programs must be combined in one way or another

I use Nuendo. I agree that they might as well combine them into one product. Or they should consider a brand new, limited, product for Nuendo specific features relating to ADR.

1 Like

Nuendo is as much the same as Cubase Pro
as Cubase Pro is the same as Cubase Artist.
And as Cubase Artist is the same as Cubase Elements.

So in short: Nuendo = Cubase Elements with a couple of more features.

1 Like

I’d love it if Cubase Pro would automatically import Expression Maps from supported Virtual Instruments (e.g. HALion [Sonic] & Opus) like Studio One Pro does. I just load the instrument and the Articulation Sets are automatically imported. No manual step is required.

All that trouble to fix Menus and Window Management in Cubase, and the Cubase Hub Menu is missing standard Windows Menu and Window Decoration buttons. Have to mouse down to a [Quit Cubase] button to exit it, unless you use the Alt-F4 Key Command.

It’s weird, because they basically copied this from Dorico, but did it “incorrectly” despite Dorico having been doing it correctly for years:

I don’t think comparing generic application interface to skeuomorphic plug-ins interfaces is fair, though.

I also don’t think comparing Cubase to Visual Studio is fair. Visual Studio for Windows is not the same as Visual Studio for Mac (a later acquisition, rebranded and then recieving some code sharing from Microsoft).

Visual Studio for Windows is a mono-platform application built with Microsoft’s own Application Frameworks (e.g. WPF)… and possibly also some third-party extension libraries. Things like “Menus in the Title Bar” and Accented Title Bars are easier to implement on Windows when you use the platform’s native toolkits - particularly for applications built on .NET Framework libraries (but probably also MFC (if they still keep that up-to-date) or VCL (Delphi/C++Builder).

I am not sure how that goes with e.g. Qt. I’ve never developed an application with Qt with that being a requirement, so I’ve never bothered to check. I also haven’t developed an application with Qt since accented title bars became a thing on Windows.

Cubase cannot be developed in that way, because it’s actually a cross-platform, predominantly single code base application. Trying to make it the same on both platforms is what gifted us the awful window management on Windows before v13. It behaved on Windows as if it were a macOS application.

It’s also why most cross platform DAWs do not use standard Windows custom controls, iconography, etc. in many areas (and they even shuck some standard key commands). They use frameworks like Qt and then create their own overall design that they themselves keep consistent across the various ports of their application (macOS, Windows, Linux… whatever). If they didn’t, then the entire look and feel of the application would differ drastically from platform to platform.

I honestly don’t think these UI quibbles are big deals, personally. I think there are bigger workflow or functional considerations worth discussing.

Emphasis on I.

Keep in mind, Visual Studio went through 2 major rewrites of the UI:

  1. v5/6 Developers Tools → Visual Studio .NET 2002
    MFC-> .NET WinForms - Windows XP Design Guidelines
  2. Visual Studio .NET 2003 → Visual Studio 2005
    .NET WinForms → WPF - Windows Vista Design Guidelines

Later versions are basically iterations and optimizations on the Visual Studio 2005 User Experience.

The changes were extensive, but this happened during a time when Visual Studio was a $799+ Professional Developer Suite with a monopoly on the Education Market while also Overlording Windows development… Like Internet Explorer did the Browser Market (except… for an even longer period of time).

Microsoft’s developer tools division was (and is) also quite massive.


The “Run” Dialog is not a priority because most people will press the Windows Key on their keyboard and start typing. The vast majority of people are not running any applications on thier system that hasn’t been registered in the Start Menu.

It’s a low priority item to Revamp, and depending on where the dialog resources are, it may not be as trivial to “revamp” as people think it is.

This is why the Desktop Context Menu is actually a double menu.

Win32 Application Resources were often compiled and then packaged into the executable or DLL files. This can include Dialog Boxes, Icons, Menus, UI Strings (Tooltips, etc.) and other things.

Depending on how the new stuff is being implemented (and I don’t care enough to “research” the implementation details), it may not be a matter of simply changing a color value - especially when it’s an old-style resource that you’d actually want to be system aware (changes color depending on whether the system is set to Light or Dark Mode, etc.).

This is the issue with DPI awareness in a lot of applications. A lot of the resources are compiled into the application and not designed for HiDPI monitors, so users have [had] to deal with sub-optimal upscaling until a better solution can be developed.

It is going to be years before Microsoft actually finishes all of this stuff. The amount of these type of resources in the Windows OS is staggering.

This is why despite fairly big UI/UX changes as Windows versions progressed on (3.1 → NT → XP → Vista → 8 → 10+), those elements of the UI have consistently lagged behind. The new stuff always looks new, but there is too much old stuff to update in one OS release.

Apple made this easy on themselves by completely killing off the old platform (OS 9) and rebuilding everything from scratch. This made it easier. But they still had this same issue going from Carbon to Cocoa… and even still some old-style elements remain in various parts of the macOS UI/UX.

Just not as much as Windows, because Microsoft cannot and will not “clean break” their operating platform the way Apple has (and Backward/Forward Compatibility) is more important to Microsoft than it ever has been to Apple.


Forgot to add that the Cubase Hub opens up when you exit the application, so the issue with having to “Double Exit” Cubase still hasn’t been fixed (Dorico has this same issue).

I don’t mind it opening when you start the application up, but it really needs to not do this when exiting the application.

Both Cubase and Dorico.

This is not true. The hub opens if you close the last document. If you quit the application, it just quits.

@Trensharo I agree with everything you wrote and you seem like an expert
But what if solving these problems gradually, starting with small things and redesigning them in every update?
Will it not benefit users?
Do you think that the developer team should be remanaged to work seriously and carefully?

No. It’s true. The main Cubase Window is only open when you create a new document or open a new project. When you close that project window, the application should exit. Or there should be an option in Preferences to not open the Hub when closing the last project Window.

To scrub salt into the wound…

Also, if you ALt-F4 on the Steinberg Hub, it closes and instantly reopens. So, the only way to exit is … via mouse click?

That’s also “true,” as I just confirmed this behavior 5 seconds ago.

EDIT: It seems the Steinberg Hub only exits if you use the Ctrl-Q shortcut key. Isn’t that a macOS shortcut? Lol (EDIT: Yes… CMD-Q is the shortcut to Quit an app on macOS - so Cubase uses the macOS shortcut on Windows and BLOCKS the Windows shortcut from functioning properly).

If you Launch Cubase Fresh to the Steinberg Hub and Alt-F4, it will close and immediately reopen the window. This is the most illogical and badly tested basic function that I’ve probably ever encountered in a piece of software.

The only thing funnier that I’ve encountered, is Digital Performer blocking normal access to the Windows Key while it has focus, and using that key for a ton of its application-level key commands.

They are solving things gradually…

That’s how we ended up with the remnants of 3+ design languages shoehorned into one application.

The fix is to backburner feature development and use a release cycle to focus on design and UX.

However, if they did that the same people complaining about design will complain about having to pay for an upgrade with very few new features and mostly just design changes.

At the end of the day, the users make the decisions - pay or don’t pay, and if enough do it green lights their strategy. Buying an upgrade “cause it exists” works against your interests. The right decision is to stop paying them until they deliver what you want.

Very little that they are adding in these upgrades is worth much. Plugins are some of the lowest value “features” you can add to a DAW, these days…


Hi @Trensharo

the hotkey to quit Cubase ist Ctrl+Q, from any context. Otherwise you can click on File / Quit


Cubendo… :rofl:… Sorry but the name just doesnt sit well with me… Does make me giggle still!

And that the correct summary of the problem. Users may not want to pay for UX updates. I believe this is because users don’t actually know what impact it could have. People are just so comfortable dealing with a flawed UX that they’re not sure what a great user experience is (easy, intuitive, fast).

Steinberg probably realizes this and feels pressure to prioritize “marketable features” like plugins.

We, the users, really need to move past this and demand improved UX and bug fixes.

1 Like

Cubase has been my new main for about a month. I am in love with it and ultimately chose it after demoing it and S1. Creatively it’s like working with a blank page vs a lined one. I feel so much more expressive inside it. But S1 does feel more fluid to step into. I guess that’s the benefit of building your code on something far technologically superior than what it used to be. Same can be said for Bitwig who ironically also had hands in creating this new file format.

Ultimately Cubase main, Bitwig, Ableton, S1 with Fl as Vst module is my setup today.
I also find it funny that both S1 and Bitwig have in common that x leads from Steinberg created S1 and the same for bitwig with x Ableton devs.

Ultimately these are all great tools that assist us in so many amazing ways and while there is no one to rule them all. Having grown up in Ableton and now worked in many. I am truly surprised that Cubase isn’t wayyyy bigger.

Also hands down the best community on god.

-Local Undo
-More Cuemix (4 is not enough The other Daws they Can Add Unlimit)
-Cpu Improve
-Audio Engine Improve
-Update Expresion Map
-Unlimited insert slots
-New midi insert modules (possibly utilising Ai)
-Something akin to a groove pool to help creative rhythms

The biggest one though is combining the 2 into some kind of ultimate product and really streamlining the process for themselves. Maybe it’s a case of too many good ideas and not enough people to catch that lightning in a bottle leading to poor product translation :man_shrugging:

If there was a DAW to rule them all. Regardless of where there are now I think cubase are the ones that can do it. I am noticing a lot of people coming to explore it now 13 has come out.

For me it was seeing a time-stretch algorithm and spectral tutorial.
I’ve already converted 2 people from Liveschool which is a Ableton learning centre and they love it so far.
That being said. The whole getting started process was very painful. I almost gave up many times which I imagine the friends I converted would have done as well if I wasn’t able to help guide as they expressed the same frustrations.
That is a problem and a bar of entry. Definitely where S1 excels the most.

Anyway. From the looks of it…Steps in the right direction. I’m hopeful

1 Like

I’d also love the ability to organise the plugins manually

As you can see that Valhalla verb is in the folder called other. Why, I don’t know, Can you change it: not that I can see. Does it literally have verb in its name: Yes.
So for the life of me I can’t understand why we can hide but not reorganise :confused:

1 Like

You can create custom sets of plugins in any way you like.

This personally would’ve been great. For users with smaller real-estate would benefit from the single row menu bar that’s merged with the title bar. (Just like in VS Code)

I’m not a Dev so I wouldn’t have any idea on how difficult it would be to implement this. But it would be a nice feature to have.

On a side note, it would also be nice to have a darker color scheme or an option to go even darker on the color wheel for the project window to something like the one shown below.

1 Like

Yeah. That Ain’t it. I’m looking for better organisation. I don’t think that’s necessarily achieved by making more folders tho. Doesn’t seem like the best way it can be done. Not pressing tho

Oh, I thought you would love the ability to organise plugins manually? Using collections you can organise plugins manually by using folders, not using folders, using lists, using collections, or any combination of these. You don’t need to use folders at all if that’s not your thing.
How would you like to organise plugins? It’s a little hard to try and help/or to get any response from Steinberg, without at least some specific details of what you want.