Nuendo 15.0.21 Maintenance Update

Dear all,

We are happy to announce the availability of the Nuendo 15.0.21 maintenance update. This update resolves a few issues in different areas of the application, including a freeze when exporting or rendering audio in a project where a video track is present.

A list with all issue resolutions can be found in the Nuendo 15 Release Notes page.

You can download Nuendo 15.0.21 from the Download page or via the Steinberg Download Assistant.

All the best,
Luis

Hey Luis,

Thanks for the update.

I was wondering where can I get like a comprehensive list of all the fixes done between N14 and N15.

There are several important bugs reported in this forum that have been ignored by Steinberg and I’d really like to see if they have finally been addressed or not.

Some stuff have been around for years, sometimes more than a decade, so one begins to wonder.

Thanks!

reading all the bug reports of N15 i wonder if there is anything working properly at all. I am really concerned about the path Steinberg has chosen which seems to be quantity over quality. I think publishing buggy and unfinished software is not the right way.

N15 is no more buggy for me than any other version.

There are some long standing issues with DOP and Folder Sync / front to back ordering in groups. Nothing major.

Yeah, I don’t see why it should be more or less buggy than any other versions.

What I’m interested in is somewhere I can read about everything that has been fixed in N15, since this stuff usually is not marketed, and I haven’t found anything about fixes coming into N15 (apart from this very update, which is about bugs introduced in N15).

I need to know this because of two reasons:
One is N14 is probably not going to be updated anymore, so I guess it is what it is. Two is Steinberg has been actively ignoring these issues for a while now, and I’m starting to believe I need to find alternatives if this is really the modus operandi we’re stuck with.
Yes, there has been that bug report topic Timo made, but it was exclusive for N15, it was closed very quickly with just a handful of bugs, mostly new stuff, and since I haven’t upgraded to N15 I couldn’t even check if these longstanding bugs have been fixed or not.

Not only in this thread, but across the forum in general, it seems that bug reports and feature requests are often mixed together.
I believe these two should be discussed separately.

Changes in behavior that come with version updates should be treated as feature requests or specification discussions.
However, critical bugs are a completely different matter.

I have been using Nuendo professionally for many years, and I have encountered upgrade-related issues severe enough to impact my work only twice.

One was when SyncStation stopped functioning properly (around version 7, if I recall correctly).
The other is the current export issue.

I am not denying or dismissing Steinberg’s development efforts.
However, the severity of bugs is fundamentally different between hobby use and professional use.

In post-production environments, these issues are not just minor inconveniences — they directly affect delivery, schedules, and client trust.
Stability of core functions, especially export and synchronization, must be treated as a top priority.

In fact, in this case, I had no choice but to revert to a previous version in order to complete a delivery.
This is not merely an inconvenience, but a critical issue in a professional workflow.

I strongly hope this perspective will be taken into account in future development.

Did this fix the issue from Mediabay not importing the correct segment from I/O points?

No, it didn“t!

Maybe you could use some diplomacy and phrase your response as, being unaddressed.

No one helps the cause of bug fixing by claiming that bugs are being ignored, since there is a process for dealing with issues and nothing is ā€œignoredā€, but rather acknowledgement comes, as per a development and management process.

Anyone claiming to have been bitten by a bug, in a professional context where deadlines have been compromised, needs to consider deploying a secondary testbed environment prior to installing updates in their current working environment, instead of coming to a forum and railing.

Well you may be right.

But if they are aware of the issues and taking them into consideration, why can’t they simply respond and say they at least acknowledge them, even if they lack a timeframe to address them or anything in that sense?

This is an official forum. The same credentials we have here are the ones for our Steinberg account. Personnel have official profiles here. They announce stuff here, they respond to some things but not others… I believe there are grounds, after so long, for calling this ignoring issues. Phrasing aside, I don’t see the issue with being vocal about it. I’m not alone in feeling this way and I know it from perusing the discussions here.

For example, they sell Nuendo as having ARA2 capability, but it is FAR from working properly. It is finnicky, unstable and a minefield. The somewhat recent addition of clip gain editing caused further problems. They have been reported ad nauseam in many topics. Steinberg simply doesn’t acknowledge them at all. Not one reply to try to understand the issues better, or get a sense of how many users are affected, apologizing, suggesting troublesome system interactions, anything. These issues persist through updates and clean installs of systems.
Why is this OK?

I’m not a person that simply comes here to bash on Steinberg. I have defended the company, products and their methods many times when I felt it was appropriate. I have publicly reconsidered things I said when I voiced dissatisfaction and later changed my mind. Every single time I point an ARA issue, for example, I state that I can still work with it and it is better than the alternatives I’ve found… I try to be fair. I try to help users here and have productive participation any chance I got, including proposing workarounds to users when they stumble upon broken functionality. But this, ahem, lack of addressing some (many) of the issues starts getting to you.

I’m sure if they at least responded, even if it was to say that I’m the only one with an issue and they can’t reproduce it and I should just let go, I’d feel different about it.

Have you seen the discussion on Workspaces? The other day I tried to use them and the way it works simply doesn’t make sense, really. I found a topic here and… It’s been the same for thirteen years! It took a user to come up with a way to edit the workspace files to make them work as they should…Steinberg hasn’t said a word.

As I said, now N15 is out. N14 is gonna be left behind, no words at all on standing issues.
What I’m seeing is that I either upgrade and take the chance of having them solved eventually or I stick with a problematic (in many regards) software. Or perhaps eat my losses and find a different software to work with, which would be a last resort I’m trying to avoid.

It’s just very frustrating and a bit exhausting. But sure, I’m all for changing my perspective…

I understand your point — testing updates before deploying them in a working environment is important, especially in professional use.
That is exactly how I operate as well.

In practice, when I encounter critical issues, I simply decide not to adopt that version.
For the same reason, I am currently holding off on using Nuendo 15.

However, if we take that approach to its logical conclusion, it effectively means we can never update at all.
If ā€œjust don’t updateā€ becomes the baseline, then it raises the question of whether the platform itself remains viable for professional use.

Ideally, users should have a certain level of knowledge to handle maintenance and troubleshooting, and forums like this help by sharing workarounds and practical solutions.
That ecosystem is part of what supports real-world workflows.

However, that is not my main point.
What I am saying is that critical bugs — especially in core functions such as export and synchronization — should not be something users are expected to work around in the first place.

From the user perspective that makes zero difference though. Like, from my perspective, what’s the difference between a bug being literally ignored versus not being ignored and simply not fixed and in either case Steinberg can’t even be bothered to show up on the forum and even acknowledge that the bug exists?

BS.

The ā€œtestbed environment prior to installing updatesā€ is called ā€œSteinberg’s testbed environment prior to releasing updatesā€.

Sure self-reservation says we should test things before getting into things too deep, but wth is with the ā€œinstead of coming to a forum and railingā€ comment? It’s as if you think it’s the end users fault for using a software as intended and then getting into trouble because it’s not working properly.

It’s software, there are no guarantees about how (well) it will work on any given system, so it is only prudent to test an application first, on a non mission critical system.

There seems to be a misunderstanding here. A lack of public response is not the same as an issue being ignored—it is, in itself, a response.

Steinberg does not provide individual status updates or confirmations for every reported issue on the forum, and there is no entitlement to a specific reply or acknowledgment in each case.

Issues are handled internally according to established processes, regardless of whether there is a visible response.

hi @Felipe_Garcia thanks for this statement on how you handle these kinds of issues and communicate them.
To be frank, you have every right to go about this in this way, it is your product, no entitlement here about what you should be doing. However, I see a growing sentiment on this forum where longtime supporters/users/professionals are disappointed by the lack of acknowledgment.
This is not out of a sense of entitlement. I think (or at least I feel) that most of these posts channel a wish to make the product better by helping out and reporting issues. But it is very human to also feel the need to get some kind of response after all this effort (reporting issues for years and providing feedback for free out of enthusiasm).

At the same time I understand that time/resources are limited so responding to every single issue is not an option. Also I think a ā€˜list’ of known issues might be bad for business in terms of marketing: ā€˜wow X has a lot bugs’.

What I’m advocating is to try and find a solution for this issue: not a perfect solution but an approach. For example: invite more beta testers. Or show what has been fixed (this is good for marketing!). Or something else that gives these people a sense of purpose in reporting issues.

I understand that it is not realistic to respond individually to every single report, and I agree that development resources are limited.

At the same time, when issues have been reported over a long period of time, the lack of visibility as to whether they are even acknowledged naturally leads to uncertainty and frustration on the user side.

I think one of the reasons this discussion feels misaligned is that there is no clear, shared understanding of what Nuendo is expected to be as a platform.

Nuendo serves a very wide range of users — post-production, game audio, music, live, and everything from hobby to professional use — and those use cases come with fundamentally different expectations.

If the underlying assumption is that updates should be thoroughly tested by each user and that any issues should be handled or avoided on the user side, then effectively the risk is being placed on the user.

This may be an oversimplification, but looking at the current approach to operation and communication, it can be perceived that way.
At the same time, Nuendo has also evolved through user feedback and contributions over the years.

The issue, in my view, is not simply the existence of bugs, but that
the distribution of risk — who is expected to absorb it, and at what level — is not clearly defined.

At the very least, functions that are directly tied to delivery should not rely on user-side workarounds or validation as a baseline assumption, but should be ensured by the software before release.

Even simply communicating that an issue has been acknowledged would significantly change how it is perceived by users.