well lots of reasons - this is a HOTFIX
if you are releasing a hotfix for ONE specific issue then you don’t confuse it by adding other ‘fixes’ or improvements. You wait for the next official release for that.
There is a long list of bugs that need fixing - some more important than others - why just that one (plus one ‘improvement’
+1
who wrote said rules!
Maybe it was already part of the build which was most stable and able to put live within a 24 hour period?
sometimes two pizzas end up ready at the same time… if ya got a big enough oven…
Got to keep the programmers ( for the Toy ) happy i suppose , i mean having midi notes not aligning for months couldn’t even trigger an emergency patch .
yes - I think that’s obviously the case. They quickly fixed up the bug in the latest build and released that - and that assumes the ‘latest build’ doesn’t have new bugs or problems introduced since 12.0.50 - and we know that’s not a very safe assumption.
I think it shows some of the shortcomings in the whole beta testing process though.
If the philosophy is “the latest build is ALWAYS the best” then why not just release the weekly build as an official release - each and every week - why even beta test at all ?
I agree that sometimes the bug fixing is a bit arbitrary - although I would suggest that a bug that has audio missing on export (when it’s not always straightforward to be able to test) is of a higher priority.
gotta love big new versions
I’m still smooth sailing on 11 enjoying life.
fiy, when it comes to software, every release is an experiment.
If the philosophy is “the latest build is ALWAYS the best” then why not just release the weekly build as an official release - each and every week - why even beta test at all ?
Did you mean this ironic?
Obviously software goes through various states of stability, especially when you add new features.
That’s not to say that it’s important when a company release software to the public (and not in a beta) that it should be stable and without bugs.
With that said, I do think it’s nice to see updates more often on software, so we get the fixes as they are being addressed.
I’m not sure I’ve ever owned a piece of software that didn’t have bugs, from video games to microsoft excel, to device drivers, to… everything.
And it only gets worse because of the rapid OS bs updates, CPU architecture changing what, every year almost, graphics drivers updates constantly etc, etc
So true. The irony of software is that we always get the best version when its life cycle is about to end, and then we can start fresh with new bugs once the next major version is released.
I totally agree when it comes down to the most basic of things as you say Exporting , Note alignment ect these require immediate attention .
It looks to me as thou Cubase is starting to go in a different strange ‘programmers software’ direction instead of music creation .
Break what works for the real world users to keep the programmers happy but at the same time take our money for those features that are broken .
Sorry going into one again 
yes…
no need to apologise - I’m in total agreement !
As you said that, the new performance bar came to my mind. I imagine a programmer working really hard to add these new separate meters for Real-Time, ASIO Guard and Peak, which look fantastic and useful on paper, but change the default behavior of a basic functionality which had been like that since forever.
As a public beta you mean? I think that would be great personally. We’re beta testing final releases that have glaring errors already - The only difference with releasing public betas is that we can positively feedback on a formal basis without this constant defensive stance that many people throw in your face when raising an issue with a live build.
It also allows users who are suffering with issues to jump on the beta as a ‘quickfix’ option.
Think it’s a no brainer personally.
A massive positive improvement would be to unique ID fixes that can be linked and discussed in a far more formal fashion than splattergun approaches.
Ahh sorry i never made myself clear enough, anything working behind the scenes to improve the system behaviour i agree with even if it takes a few point updates to get it right but what i really meant is if you look round the Remote Forum it’s full of script programmers and i feel the way the Patch was worded it was aimed more towards them so they could carry on creating their own scripts instead of CUBASE users of all verities being able to plug and play their controllers
I don’t know, you sort of need Beta tests to be a controlled study, otherwise the devs get inundated with bs reports from people who did some weird mobo tweak, or didnt match their RAM speeds properly, or haven’t updated their OS or drivers in 3 years.
Then you have resources wasted, and end up with more bugs.
There’s too many variables, there’s just always going to be bugs. It is the law of software.
It’s not like we in the audio industry haven’t know for 30 years - get your system working, don’t update anything, unplug the internet. Literally one of the first things I learned in AE school.
I have bought 12, but I use 11 because it is absolutely stable and that’s more important than having the latest version for me. Once 13 is released, I can choose between 12 and 13… and I’ll probably use 12. I usually stay a year behind, which always seems to keep me grooving.
I mean, it doesn’t really change anything does it? If they do the beta program you want… well… you’re just going to be dealing with the bugs in that beta - potentially - more bugs than what you are dealing with now…
Yes, but this is public beta I’m talking about.
i.e. pre C12 would have the closed beta testing program, after that point of live release they can release weekly, bi-weekly, monthly updates (whatever the private testers get) for those who want to opt in and provide feedback on features discovered in the wild.
Otherwise, we have the situation between 12.0.40 and 12.0.50 - 3 month wait for issues that were probably fixed within the first month of that cycle.
I don’t rely on Cubase to make money, but if I did I would like to have the option for hotfixes and not having to wait months when elements such as MIDI events are off-grid. In fact, that would be a very critical aspect for me.
that wasn’t specifically a call for a public beta program - but I think it makes sense - although weekly might be a bit too much 
Personally I don’t feel the current system is working particularly well and something needs to change - we did have a public beta program some years ago.
100%