Cubase 12.0.20 maintenance update available

I don’t think that is how it works. Everyone is thinking of Ableton which I do some beta testing for but that is because I paid for the product. Anyone can join if they have already bought the product, and by that I mean the major release they are testing.

When I had Ableton version 9 they allow you to join their open test group for beta testing of version 9 changes only. But they do not invite anyone to test version 10 before it is released. Like with 11, only once 11 was released was I then invited to their beta test group again for version 11. In essence we are invited to test incremental updates on product we have already paid for. I could be wrong in this but I think it’s not for major paid updates before they have been released.

If it was Cubase we would not be invited to test C12, only 12.0.10 etc if we had already bought and paid for C12. That’s the Ableton model I think.

Otherwise companies are giving their latest software to anyone who wants to test it for free and it could get cracked or they could post info about it on the internet before it is released. Plus there is no incentive for ppl to buy it if they just get a copy to test for free without withdrawing licenses etc.

The process here is probably requirements gathering, functional spec created, design documents, developers code, dev unit test their own code, they then move that to a test environment with all the other code bases. Then there will be some form of end to end testing. Then a user group will start testing this and they could be given user test cases or “Stories” to follow. There can be automated execution of test cases as well. That is probably performed by an employee testing team. Only then will it be released to a closed test group to find issues which are then fixed before a Gold Copy is created. I guess is is that final alpha test group you want to join, not an open beta test group.

I do see Ableton has a closed “Alpha” test group which ppl can apply for but that is a closed group like all other vendors. So even Ableton do not test their new releases to wide open beta test group either.

But for incremental free updates it makes sense to open it up I guess. Then learn from those changes and implement that into the next big release some how.

I do not think there are any DAW manufactures that have open Alpha test groups for new software they have yet to release. But I could well be wrong of course, would not be the first or last time lol

Then by definition, it is not a beta test.

Beta testing is just opening up a test of software bugs to a wider group of users, that’s all. It is exactly what Ableton do. They will add a new beta version on their beta test site and they add release notes of what has changed. You go to that site download the change version and used it to create projects and note back any issues via their website. We are testing new items in the code.

It’s just their major releases are harder to get onboard to test that’s all.

Maybe that is not a text book definition in one place but it will be in another. I see software vendors perform E2E testing where data goes in and then a report is generated. If they can find the inputs on the reports they are happy the E2E part is complete. But then I have see some software vendors check every single calculation along the way in E2E even though the same test will be done in UAT. There are definitions for these things and some vendors probably stick to that but others do variation in each of their testing phases.

I have even seen developers being asked to create the Use Cases which is utterly insane. But the end client thought, “I paid them to create the software and I want to get extra out if them”, what a foolish attitude that was lol.

After 30 years of software implementations I have given up trying to say this phase should only be done like this or it’s not really correct. The end client usually wins that argument anyway, it’s just too exhausting.

Yeah they should really open up to a Long-term Support scheme, like Blender did.

For example, they stay with the release schedule like it used to be :
1.0 > one year > 1.5 > one year > 2.0 > one year > 2.5 > one year > 3.0 > etc
The .0 adding new major features, improvements to the engine, better workflow, GUI updates for older plugins, etc.
The .5 adding new plugins, minor new features and improvements to existing ones.

Each major versions keep receiving maintenance updates regularly for 4 years :

For example, you have 1.0 and that one bug that has been driving you nuts for all that time finally gets fixed in 2.5 or one of its maintenance update. You also benefit from the bug fix, because the three major versions that have preceded the current one are also receiving the bug fix.

What we are actually expecting from paying for a version upgrade, is to have access to new features, workflow improvements, plugin updates, and things like that.
As customers, we are NOT expecting that the version we currently use stops receiving any maintenance updates, just because a new major version has been released !

With the Cubase 12 release and the transition to the dongle-less licensing, Steinberg should really start considering adding LTS to their products.

Let’s make a poll. That should be very interesting. And please be honest.

I upgrade Cubase because :
  • I want to access the new features
  • I’m doing it for bug fix / compatibility

0 voters

Yeah , that is so difficult because I want both lol, new features and bug fixes when I upgrade. But I do think if a bug is fixed in 12 and it also resides in 11 then it should be fixed in both versions for a period of time.

BUT if the question is “what do I pay money for ?” Well that is for new features, I expect bug fixes for a period of time for free. Otherwise it’s like saying “hey we sold you something that’s broken but if you pay us again we will fix it for you” :slight_smile:

So I’m going to have to say I upgrade for new features but that is only because I expect bug fixes without upgrading.

2 Likes

@Louis_R How are these two options mutually exclusive?
I guess I’m one of the few that has never really experienced any critical bugs in Cubase over the 30+ years I’ve been using it. Sure, minor bugs, inconsistencies, half-baked features—I’ve got plenty of those. Most of the time, you find work-arounds for these minor issues. Not saying I’m perfectly happy with that, but it keeps me working.
Personally, I would happily pay 10x the cost of a license if Steinberg announced they would fix the MIDI Remote mess once and for all. Or how about the Expression Maps (yeah, I don’t like how they did those)? I guess those two are my current pet peeves.

Just like you, I’m sure, I wish there was a functioning feedback loop with Steinberg devs and their end users. Often times when a new feature is added, I feel it gets abandoned before it has reached its full potential and that is where most of my frustration lies.
I will say though, I think it is fantastic that devs show a lot more presence here. I’m hoping it will, at least to an extent, close the gap between devs and users.

On a side note, the Issues and feature request Wiki you so valiantly created, have you gotten any feedback from a Steinberg representative on it?

2 Likes

Exactly!

We’re paying for a finished product, fixes are Steinberg’s overhead - not ours. If management are putting priority into new features at the sacrifice of immediate or long standing bugs then it’s on them to get the balance right.

Problem with a vote like this as it could appear that everyone wants more new features over bug fixes if the first option is highest. When in fact it just means that people don’t support a “paid for” bug fixing model.

8 Likes

It’s not just Cubase Pro that has a number of bugs that have never been fixed and that has new ones creep in every update. It’s seems like every DAW we own, every hardware driver, every piece of software, and every plugin are plagued with the same problem to varying extents.

At first glance one might think consistently buggy software is the result of marketing pressure to add new “features” which result in upgrade income that is needed to enable the company to survive. The problem with this is that “new feature” updates take precedence over bug fixes. That is partially true I believe and this results in the never resolved bug problem.

Then there are plenty of examples where the developer of the software charges an annual “maintenance and upgrade” fee instead of requiring users to buy periodic upgrades. In theory they should have the funds needed to squash bugs and add new features because they have the steady and predictable income to support it. However, the software of these companies exhibit the same constant buggy situation and are no better.

So, what is the real source of the unfixed buggy software problems? I think it’s the current pace of technological advancement itself. There are transformative changes taking place (like Apple’s new M1 chips, etc.) which require massive changes to operating systems which in-turn require massive changes to all the software layers under it. This causes the software manufacturers to spread resources between teams that try to cope with basic technology changes, teams that work on old and new bug fixes and new features to enable the sales necessary to fund everything. What a mess!

I wish that users would send a signal to hardware and software developers alike that we have all the new technology and software features we need for now and that they should concentrate on tuning hardware and drivers and fixing bugs exclusively for the next year or two. This would require some new mechanism to pay these companies to do this optimization and bug fixing work during the year or two this work is underway. I for one would gladly pay the same annual fees (in the case of Pro Tools) or the annual upgrade cost (in the case of Cubase, Studio One, etc.) to get this all resolved.

3 Likes

I agree with all of this, except:

What Avid does is just scam in this regard. They are charging a whole lot more annually for less features than Cubase has. And on top of that you never own the product.
So when you’re stopping the subscription you have nothing and you lost way more money than anywhere else.

Steinbergs prices are reasonable and OK. Of course there are also other products like Fruity Loops (or Logic I guess?) where you buy the product once and all other updates are for free. This would be very welcome of course, but I don’t see that coming.

2 Likes

I neglected to mention that we own Pro Tools Perpetual Licensees , we do not purchase a subscription (and never will!). We do purchase the annual support and updates plan for each of our Pro Tools seats…which is different than the subscription they offer. If we stop paying for the annual support and update plan we continue to own our Pro Tools seats and continue to use them at the state they are in at the time…presumably forever (or as long as our hardware is compatible with the version of Pro Tools we are now locked into ).

I will agree that AVID’s annual support and update plan for their perpetual licenses has not had much value for the past few years…because of the problems I alluded-to in my earlier email message.

My willingness to pay the developers an annual fee for a couple of years while the undertake only performance tweaks, compatibility fixes and bug eradication is based on a willingness on the part of each developer to actually give us value for what we pay them…something many of these companies have forgotten how to do.

The only companies that can afford to provide “free” reduction updates for life are those that successfully sell hardware and/or other software add-ons that are their source of revenue. If their main source of revenue is related to their main software product then they must sell maintenance updates and new feature updates. The problem is that maintenance updates and new features updates are frequently not be undertaken simultaneously…the marketing and sales departments often win-out…because company survival depends on income rolling-in.

1 Like

That affects low level/framework development sure. But I feel that most bugs that get reported sit within the usability/high level development areas.

What is perceived to affect the bottom line most gets priority, so ultimately falls on the consumer to vote with their wallets. Steinberg appear to be doing well, so… well… That’s ultimately the source of buggy software - that it sells.

1 Like

I agree. That was my point. If users (customers) demanded bug fixes, performance optimization, and compatibility within the industry as a whole and refused to buy buggy, poor-performing updates perhaps we would see change.

New “features” are wonderful if they are truly needed (not marketing hype) as long as the base software performs well and is not buggy!

2 Likes

That is exactly why I am requesting long-term support for older versions.
A lot of people don’t feel the need to upgrade every year, and that’s why maintenance updates should keep going for longer.

What would happen if MIDI Remote doesn’t get fixed in time before the next version ?
Without long term support, we’d have to pay for the upgrade, because Steinberg would simply abandon previous versions.

This is the sad truth : Most of the maintenance updates get released within the next 6 months following the release of a major version. Then when you’ll upgrade to the next version, there will be like more than 50 bug fixes. I’m very sure Steinberg is doing that intentionally, they must just say “Uh, the next version is expected in 4 months, there’s a lot of new features and bug fixes incoming !” Yes but please fix them for previous versions users too ?!

Thanks, but how can I get feedback from Steinberg when users don’t even bother to check it out and say whether or not they can reproduce the bugs?
My Wiki post has more than 650 views, but the links have only been clicked a few times, yet those are extremely legit and serious bugs that can be reproduced in under 30 seconds for most of them.

1 Like

Hm. Mostly for the need to migrate to ARM based CPUs. I that a feature or compatibility thing?

It is compatibility. Like Apple M1. But for Steinberg it’s a “new feature”…

Is still bugging me a lot: Hurray, they said, we give you M1 support with this chargeable update, isn’t that a great feature? Well, I said, where is my free M1 then?

Hi,
Whats the expected date for a maintenance update? 12.0.20 is very laggy for me at the minute. Takes an age to open a project and loading a plugin seems to freeze the screen. It works eventually but just takes a long time.
I’m hoping a new update will have things back to normal.

Thanks

IMHO
It’s a compounded issue from neglect by continually kicking the can down the road and now many of those fixes would affect so much that has been added.

They basically put themselves in a corner w/many of the issues that have been sitting here for years so at this point it’s either unfixable or they would break something else.

IMHO Steinberg/Yamaha has enough income to recruit one or two more qualified senior programmers. They would start again from scratch and meticulously examine every line of code in relation to each other, and in a matter of a few months they’ll eventually end up with something that is perfectly coded and has no bugs.

3 Likes

There is considerable externality in software like Cubase - you are running on two different versions of each of two different operating systems, using numerous libraries, relying on countless drivers and attempting to work with thousands of third-party plug-ins. It is overwhelmingly likely that all these dependencies are not bug-free. Indeed, the toolchains (compiler and linker) might contain output affecting bugs.

I think you underestimate the number of lines of code in a major application such as Cubase/Nuendo, also how long it takes an outsider to become familiar with the layout of a code repository.

Code review speeds of more than a few hundred lines per hour are impossible to achieve with any quality. Code review can be subject to confirmation bias, especially on dealing with subtle bugs; I have found bugs in colleagues’ code that has been through multiple code reviews over several years. Indeed, I remember looking at one program where the parameters to the very first operating system call in main() were incorrect.

Steinberg have internal testers (look at the credits) as well as beta testers. However, there is only so much that can be done with an ever-moving codebase.

Zero bugs in a codebase of many thousand lines of code written by human software engineers is mathematically implausible.

3 Likes