Should Steinberg implement a system for deploying hotfixes?
Yes, we shouldn’t have to wait for months for simple fixes!
No, I don’t mind waiting…
0voters
OK, so this timestretch bug is REALLY cramping my style over here. I really want to be using 6 now, but I can’t. I rely too much on timestretching, and I rarely work at 44.1kHz.
I’m quite surprised this was not caught during beta testing, but that’s beside the point. This has been a pattern with Steinberg in the past, and as they’ve acknowledged that the time stretching bug is now fixed, I have to ask: Why don’t we have it?!
I feel it’s high time Steinberg implemented a system whereby simple hotfixes could be installed and de-installed automatically once the full release is ready. Other companies have managed this, and it works just fine. It’s really getting difficult having to wait sometimes months for very important bug fixes! More and more companies are going to public beta testing to ensure the quality of the software before a major release.
This kind of bug is not what most of us would consider minor, and for those of us who choose not to work at 44.1kHz at all times, it’s a pretty much a deal breaker.
I was really hoping quality control would improve dramatically post Yamaha acquisition, but this is, to say the least, disappointing.
Brains, I wouldn’t be so sure. That might happen, but in the past, after a major new version release, the previous versions haven’t often been updated further.
Well, looks like the majority of people so far like the idea of a system for hotfixes. I think it’d do much to help people get back to work, how they want to work, when they need to be working!
Wow! This is impressive. I’m really glad to see that Steinberg is taking its duties to its customers more seriously. This is extremely encouraging.
But, the timestretch thing remains a pretty major bug, and I’m really dying to use Elastique Pro. I’d so love it if they updates came faster and didn’t necessarily involve an enormous patch. If they’re over there in Germany using it at sample rates other than 44.1 as we speak, that’s a little irksome.
We will launch a pre-release 6.0.1 shortly after 5.5.3 is out of the door. It will include proper timestretching with 48kHz and resolves several other smaller issues. Actually we are pretty good in time, so I’ll post an announcement soon.
Good! Thanks, Helge. I’m sure you meant “at all other sample rates”, right? I always work @ 96k.
Anyway, great to see you guys more on top of things lately. I think, and it appears the majority think that a system of hotfix deployment might be really useful in future.
My idea is have Cubase be able to automatically check for fixes and download/install them if a user clicks “Yes”. These would be simple fixes for broken features–major releases would, of course, contain said fixes.
If Steinberg takes a “keeping musicians productive” tack toward releases, if this becomes like an internal slogan at Steinberg, I think you could solidify your position as the de facto world leader in DAWs.
This software is looking and feeling more and more like a “standard” all the time. Congrats on that! Your hard work is paying off, and I’m finding this software increasingly recommendable to musician friends; there was a period where this wasn’t exactly true.
I’m all for that, too! NI’s public beta system seems to be paying dividends so far in that their software is getting more solid lately. It took them over 11 months to fix a sample previewing bug in Battery 3.0.6, for instance. It’s gone as of 3.1, and 3.2 beta is doing just fine so far.
Companies can learn from this! The DAW world is becoming increasingly complex, not only on the side of the host program, but VST, AU, and RTAS plugins add a whole new dimension of complexity, not to mention ReWire syncing and other novel systems of getting these applications to talk to each other, e.g. Melodyne.
If a feature like timestretching gets broken, I think it’s really important to have a system to a) allow users to report immediately and with little fuss, and b) deploy a fix for it as soon as it’s been sorted. Packaged releases of bugfixes and new features are one thing, but if it’s a simple bug that prevents use of a crucial feature for lots of musicians, it ought to be sorted right away so people can get back to work. Hotfixes should cover major bugs that prevent us from working how like, for which there is no workaround. Regular updates should contain hotfixes, as well as fixes for relatively minor issues for which there might already be a workaround.
As you (or I) say, the elicenser should be expanded to include downloads of patches/hotfixes etc
(as of now it cannot update itself) and if necessary require auth codes for dot versions and allow point versions to “flow” unimpeded.
This would be much more efficient than the FTP/Forum. When an update is available instead of announcement/begging for update, we’d be talking about how well it worked and where to next.
Yeah, Brains, I think it’s an idea whose time has come.
I’m sure the technical limitations as they currently exist, could be, like anything else, overcome.
It’d be so nice to have, say, 30 people report a bug in a new version Thursday evening, and by Friday afternoon, the fix is available from a menu within Cubase or the eLicenser app. “This fix addresses an issue with _______. Do you wish to apply the fix? ”
And then, it’s back to work. If it happens to break something else in the process, just return to said menu/dialog, and choose “rollback”, and you’re back to normal.
I’m not s software programmer, but I am a web programmer and have worked in business structures both good and bad, so I can at least offer some tips on this.
First and foremost is an interactive user base like we have here. This allows the most brainstorming of ideas, and the best ones will eventually rise to the top.
The other things to look at are the Steinberg structure, the Yamaha structure and how much Yamaha invests in the Steinberg brand… etc…
If Steinberg remains an indy within the company, then their business structure is pretty much set, and they won’t be able to increase (much) to additional departments like weekly builds.
The worst would be if Yamaha tries to shove its megacorp policies down Steinbergs throat, which honestly I don’t think it would do. But if this were the case, then there would most likely be a restructuring and years of adaptation to get where they are now.
The best case would be Yamaha allowing Steinberg its independence, yet funding the brands advancement by budgeting new departments to increase it’s popularity, growth and quality.
Nightly or weekly builds is a hard transition if it is not already in place (Mozilla had this from the start, but a lot of other companies work in a different way). Not to mention, it is risky, and would have to be installed at the discretion and responsibility of the user. For this kind of thing, it would be difficult to align with product stability and reliability… because a bad bug fix could potentially cause all kinds of problems on both the user and company level.
I think Steiny is working at an intermediate level here. Giving attention to issues that arise and addressing them as fast as they can without throwing band-aid fixes at us. It makes logical sense for a full fledged commercial program where a lot more than a browser crash is at stake.
I think this sort of thing is a matter of the importance of the bug. If for example, doing some string of events cause a crash, then simply put out the report, people can avoid doing such a thing until the next update to 6.0x or whatever. It’s really not a big deal and expecting to have a .00 version of a program like this work perfect is entirely unreasonable.
BUT, the timestretch bug is a exception. Let me start by saying cubase 6.00 is the best .00 version of cubase i’ve used. It is generally quite smooth and amazingly stable especially considering all the new features they packed in. This unfortunately led me into starting a big major project in 6.00 only to find a couple days in that I can’t use time stretching, a feature i had come to love and rely on. Now i’m stuck doing only crossfade based and realtime quality time stretching on this project and i’m extremely upset about it. I’ve found other bugs with 6.00 but none of them actually affect the quality of my work. This does however, and as such it should be fixed ASAP as i cannot possibly be alone in this. What’s worse is i cannot just go and open the project in 5.52 it says it has corrupt data.
So in short, for super important hotfixes, get them to us the moment it’s physically possible. For well tested stable updates, take the needed time to get them as good as possible.
Xaq, that’s my thinking exactly. If a “hotfix” breaks other things, there should be a very simple rollback option available. This doesn’t have to be rocket science–just a means by which people who have started projects they can’t finish because of a major oversight (timestretch bug) and can’t open on previous versions have a means of getting back to work right away.
Yes, things like this are an issue, period. It was a big oversight. I’m not suggesting they deploy ‘nightly builds’ or anything of the sort. I’m suggesting that when there’s a MAJOR bug discovered, like this one, that it can be fixed without having to wait weeks for a relatively major release. A hotfix targets, in most cases, a single known issue that is keeping people from working. It is contained within the final, stable release that also targets other, less critical issues.
^
Alternatively, NEVER use a .00 version on anything important.
Better still, unless you can’t get by without the new features, don’t use a point-anything version until the forum members seem to be finding it OK …
… and don’t be influenced by those threads where everyone says “this is the best ever DAW there’s ever been anywhere in the universe, and there’s absolutely nothing wrong with it - and we know that, because we’ve been doing exactly the same thing with it every day for a fortnight”.
