To be clear: No manual is flawless. It is impossible to cover all aspects of a feature- rich DAW like Cubase/Nuendo including its associated plugins and VSTis. However, judging by the amount of complaints here in this forum, there seems to be some extra room for improvement when it comes to Steinberg’s manuals.
For example:
missing/incomprehensive/outdated information
more graphical aids that help understand complex features
glossar for used Steinberg terminology
overviews on symbols
comprehensive release notes
Why not use and channel all the useful information provided by members of the forum to help out? A New Documentation Tag could not only help to identify parts of the manual that needs to be polished up but also provide useful examples how a specific topic could be approached. Moreover, it would be a lot easier to find these threads if they shared a common tag.
Maybe it’s wishful thinking but this could also provide an opportunity to improve communication between Steinberg and its user base. Something, we would surely highly welcome and appreciate.
This feature request is not about pointing fingers at Steinberg’s documentation team (we don’t know what’s going on behind the scenes, anyways). This request is about channeling information in the most constructive way possible so that everybody wins. We all want to see Cubase/Nuendo prosper!
I’ve done a notebook lm that utilises all my Nuendo work. Transcriptions of all planning docs for videos and the videos of course themselves also used as sources. Also Including the official manual too. Etc.
It works really well. Just ask it questions. etc. I haven’t made it public yet but will do soon. In fact I’m kind of replying here to remind myself to do it.
Of course you’ll need a Google account to access it.
Along similar lines, and I don’t know if a pin or tag is best, but over the years there are a lot of missing Key Commands. It would be nice if once verified, they could be documented here.
And also, making sure the mouse-over tool tip verbiage is the same as the Key Command name?..consistency.
I think this is a great idea. There have been many times where I’ve gone through the manual word-by-word without resolution to important questions like “why do .bak files get erased on Windows and not on Mac?” and "is that supposed to happen, and is it by design,” and such. Asking questions with a “#Needs Documentation” tag or “#New Documentation” requirements would be a great place for the team to identify where deficiencies in documentation lie. It could be a valuable “to-do” list for the SB doc people in my opinion.
That would be a typical request for a documentation tag: An updated list of default key commands (all of them, not just a selection) for each (current) version. This list could also list changes with regard to functionality or name (e.g. the floating transport bar, formerly defaulted on F2, changed its name and location in key commands in C13).
I’m a fan of manuals that are well written, well maintained, and have a good index for topics, terms, problems, and so on.
I often read the Cubase Pro manuals in this case, where they explain how to do something step by step, usually more or less clearly. But I still lose a lot of time trying to understand some things properly, or trying to see the real benefit of other functions.
In short, for many functions, menus, and parameters, these manuals dont give enough space from the start to explain: why is this feature important? What problem does it solve? What does it allow you to do, and what does it not allow you to do? When should you consider using it? And yes, after that, the how.
Some documented examples written down properly would also help. Very often, parameters are just listed, explained in one line, and that’s it. You are supposed to already know why they matter, what they are for, and when to use them.
For that reason, I would rather see the main manuals kept up to date and improved — the getting started manuals, reference manuals, operation manuals, plugin manuals, MIDI manuals — instead of having forum threads scattered around to fill the gaps left by the manuals.
Yes, this is the entire purpose of the feature request (from my perspective) - it’s to flag topics/processes/features that are currently poorly or incompletely explained/detailed in the official product documentation so that SB can go back and expand upon them in those docs. The forum is already a collection of distributed “how-to’s,” any number of which could have been addressed by a simple link to the manual IF they actually took the time to create meaningful, detailed feature descriptions and explanations rather than minimal (and obvious) single-sentence blurbs of what a button is named.
The request isn’t to create and maintain yet another body of work. It’s a request that SB do a more thorough job in providing valuable, well presented documentation in those manuals. It actually helps “do that job for them” by providing them with a list (by way of reading the FRs) of what topics people find deficient, and to give examples of where the manuals could be improved. Win-win for everyone.
I like Cubase and Dorico, and have hopes for better integration of the two in the future.
I used Sibelius in the past for writing. It was fine; I ditched it because it was clearly very old software, and there were some clunky things I did not like.
That said, their documentation was/is really great. With a detailed Table of Contents, and good search function, you could find what you needed. The documentation spelled out the commands/settings, what you would get, and not get, and a good explanation. (Yes, I know Steinberg founders came from Sibelius.)
I get none of that with Steinberg products – again, I am not a hater, I use and like Cubase and Dorico, and I’m not going to stop. But when ChatGpT and Google gemini give me better explanations that the actual manual, you know someone at Steinberg could do better with appropriate resources.
Maybe an intern with a subscription to Claude, and access to all of Steinberg’s build documents? Or use an AI enhanced search function in the current manual?
I was always pondering the idea if it would work if Steinberg provided a WIKI for users to edit with exactly those Howtos and documentation snippets that are usually hard to find again in this forum…
I know that essentially it is the responsibility of the software vendor to provide a manual and not outsource that to the community, but there are always topics that might not really fit into the context of a product manual (like e.g. my tutorial on how to use Windbg), but could still be useful.
I guess the issue with a Wiki is that you might need additional people to “moderate” it, and the question who should be allowed to edit the Wiki…
