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:
Goals
Conform with Windows standard by moving away from the “free-floating” global menu concept
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
Non-Goals
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
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.
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!
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.
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
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.
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?
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.
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.
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
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?
