About the new windows handling in Cubase 13 (Windows only)

Hi everyone,

We are creating this topic in order to clarify and provide a quick guide to the new windows handling on Windows.

Although it came with certain advantages, the former “free-floating” global menu concept was ranked by our customers as one of the top priorities to address for future versions. Furthermore, this original concept did not conform with windows’ UX guidelines.

This long-standing priority was therefore addressed in the 13th version with the following goals and non-goals in mind:


  • Conform with Windows standard by moving away from the “free-floating” global menu concept
  • Compatible with Windows’ snap layouts
  • Improve accessibility
  • Minimize the reliance on the hub as a distance-line window
  • Ensure consistent lifecycle between full and minimized arranger window
  • Merge the project assistant into the hub
  • Maintain or speed up usability speed


  • Renovate the hub

We understand that this is a major change in the workflow for many of you, and that this requires a little bit of relearning. You will find below a few new tricks that will facilitate and speed up your daily workflow.

New features

  • The free-floating global menu is discontinued, consequently the hub is prompted when there is no other window available or the last project was closed
  • The news of the hub can be disabled by disabling the preference General / Show News in Hub
  • Every main window has its own customized menu allowing quicker actions within one screen
  • Every window’s custom menu can be toggled by right clicking on the title bar, exception made of the hub
  • Menu can be highlighted and navigated by pressing Alt
  • Menu can be temporarily reactivated by pressing Alt
  • When closing the project window, the app remains opened via the hub to allow to switch to other projects or windows
  • The application can be closed from any window by pressing Ctrl+Q or clicking on File / Close application

Known issues

The following issues are known to us and are scheduled for upcoming releases:

  • The hub reappears when not needed, for instance when double clicking on a project file in the explorer.
  • The hub doesn’t disappear when it should
  • The key navigation works erratically in the hub, the known workaround is to press tab, after which key navigation should work again
  • Some key commands work differently in the rest of the application when the hub is opened
  • Quit the application is only offered by the hub when the hub is the last window opened
  • The hub cannot be closed by pressing ESC
  • The menu’s color scheme does not follow Windows’ dark scheme or the rest of the application’s color scheme.
  • Snapped windows are not correctly restored.

If you are aware of any other issue, please let us know by posting in this topic.

We hope that this topic will answer most of your questions!


Application doesn’t ‘remember’ the snap layout settings They aren’t recalled correctly when opening a previously saved project.
Result is that Windows taskbar obscures the bottom of the Cubase window(s)…in my case Project and Mix windows are both cut off by the taskbar, So I have to re-snap the layout every time I open a project.
More here

Hi @pmallett57

Sorry I had overlooked at this one. This should be fixed in the upcoming release. Please let us know if you still experience issues afterwards.


1 Like

I’ve heard that some folks are able to minimise all open Cubase 13 windows by minimising the project window. Is this how it’s supposed to work?
If it is, it doesn’t behave this way on any of my machines, either at the studio or at home.

Not listed above but, since you mention Windows standard behaviour, how about returning to the standard with being able to use the keyboard to navigate windows and dialog boxes. For example-

  • Being able to TAB around dialog boxes e.g. Export, Media bay

  • Having a Button or field highlighted on dialog boxes for quick use. E.g. Export on the Export dialog, the search field on Media Bay (even the Search Media Bay key command doesn’t do this now!)

  • Alt + menu item disappeared some years ago. Yes, I understand you’ve made most menu items available for key commands but it’s not always as efficient. Two specific key commands for File>Save and File>Save As rather than a combo Alt+F > A or Alt+F>S … this might be a throwback but I miss the functionality.

Whenever I have to mouse for a non-mouse function I’m wasting time. Many users learnt this years ago and use the keyboard as much as possible with the mouse only when needed.


Hi @dbh

Just to clarify, most of the requests you are asking for are beyond my domain I’m afraid so I cannot bring much more info to this.

Regarding this point specifically:

This should be back in C13, or am I missing the point?


Thanks for the quick reply. Actually, now that I check it IS kind of back - there’s no underlining or highlighting of the letters so I assumed it was just Alt to reveal the menu. Now I see some of the old Alt key combos work although that’s now trial and error as nothing is marked and no indications given. Good start anyway!

Correct the underlining of the letters is still not available nonetheless, this is a known issue. Thanks for confirming that “alt is back”. :slight_smile:

1 Like

If this is a known issue, maybe it will come back… We live in hope!

Hi @Armand, we had discussed an issue with regards to Alt-Tab handling in Cubase in a separate thread. This has a direct implication on Cubase window handling, so I wanted to post a link to that issue here for completeness’ sake:

I really hope this will get addressed soon - it is such a daily and ongoing annoyance, trying to manage multiple windows on multiple screen in my workflow.

1 Like

Hi @Timo00

Thanks for upvoting this post. We are trying our best to schedule this and find a way to reproduce this here in-house, so far unfortunately we’re unsuccessful in doing so. If you or anybody else finds what causes this, or if it can be reproduced with other applications than Cubase, it would be very helpful to post this information here: Cubase windows handling (on Windows) is still off in Cubase 13

1 Like

That’s unfortunate that you can’t reproduce this Alt-Tab issue.

It only happens with Cubase windows, not with any other applications that I’m running on that system, so this is definitely unique to Cubase (and/or how it interacts with Windows).

I’m glad you’re continuing to try to reproduce this. This issue manifests itself in a variety of guises while using Cubase (in addition to the repro steps I had already shared for one particular case), and if I can, I’ll try to post a video and repro steps of a different manifestation of this.

I posted another thread.
Check it, pls. my post

HALion 7:When I open the lua edit window, the order of the window is wrong

Another view on menu and windows handling. I read somewhere here in forums that Cubase programmers did rework the Cubase windows so now we have clean Windows title bar in one row and menu bar in second row. I read that it is Windows standard and Steinberg should follow it.

Yesterday I upgraded my WaveLab to version 12. I thought it’s also Steinberg product, but no! What a surprise - it has title and menu in one row.

So the question to @Armand and whole Cubase team - why we have less space in Cubase just to have two white rows while WaveLab has one and fit in GUI? I know that we can hide menu. But why? It would be better to hide the title bar, because it has no functionality while we are working for many hours, days!

I’m programmer and as far as I know there is no problems with Windows standards if application has its own unique graphic libraries and window controls.

WaveLab has FullScreen function that gives another row for GUI, but Cubase still don’t have such. Why?

Hi @ArthurNeeman

Thanks for your invaluable input. As a matter of fact Cubase is using Windows native menu, which is then based on two rows. Having all in one row is known to us nonetheless. :slight_smile:

Although belonging to the same company, Cubase and Wavelab have almost no code base in common. Same goes for Dorico. That explains why the look-and-feel can be different among our apps.


1 Like

Seems like a lot of fuss over 30 pixels of screen space.

When you’re on a laptop, every pixel counts. I really miss that all in one bar.

1 Like

I don’t know if this one has already been related, seems not.
I am using 2 monitors with W11, the main with 8K resolution was physically on the right, the second an old 1K on left side.
After some reorg the second was physically translated to the right side. I adapted the windows display settings then started Cubase 13.0.21 and oppened my last project closed with some windows opened on the second monitor (mixer, plugins) and discovered that Cubase has not adapted its screen management to the new configuration : all the windows opened were still on the left area of the main display and totally inaccessible to be moved on the right place. Normal behaving W11 app manage this correctly, opening in the monitor where they have been closed, independantly of left/right consideration, just taking the correct info from the OS.
… Cubase is not the only to behave poorely in this area, Native Access closed on the left side, opened on the left side … lost in the void and uneasy to move. I had to change back w11 display to get hand on it and move it to main monitor, then change back to correct setting and move it to the right side :wink:

1 Like

Many applications that uses Windows native menus, including many of Microsoft’s own, support a full screen mode. Is this something that could be implemented in Cubase now that you’re using M$ API for window handling?

1 Like