Doktor Avalanche
Sure the monthly updates are better than X3 and before, sadly however the QA results seem to be about the same. I don't expect bakers to find every issue, QA is hard, the product is complex, it's impossible to find everything. Heck ... But I still do question the model of releasing unstable or buggy software with bug fixes at the same time.
Monthly is great if all we are is beta testers, and some people want to be, and that is fine by me. The situation we have now basically. But for the rest of us, we want to run on stable releases, and there needs to be another path for us to follow. If there was a situation where there were additional stability releases every quarter with a feature freeze, a true alternative path to follow, that would be a huge improvement. That could run in parallel or part of the normal cycle. Whatever...
To say that there is no demand for stability releases (as has been stated only recently) is a ridiculous statement. This is audio software we are talking about. Some of us just want to spend time recording without issue.
Of course the arguement would be you can simply roll back, this is true and is a good feature... However..
a) We are still put into the position of having to be beta testers whether we want to or not when we upgrade. That's a pita when all some of us want to do is record, and with paying customers is a big no no.
b) Rolling back may resolve an issue, but just leaves us with other different bugs to cope with. You takes yer choice.
... something seriously needs to be done to improve the current situation. Bring on regular stability releases and schedule them so we know in advance is my opinion. The current model is a good start, please tweak it.
I fully agree with the excerpts I've shown. In fact I'd been thinking lately about asking for a new feature freeze, with a few months of nothing but consecutive bug fixes. By all means, tighten the loose rivets, especially the known ones, before aiming to set new monthly land-speed records. Get your balance on the highwire before you start juggling an ever-growing number of bowling pins. That's not anti-evolution, it's just common sense.
For me, at least, this is crucial because I started my subscription in July and have stayed with Hopinkton. I've not been tempted enough by the new features added since then to abandon my more-or less stable perch. (To be honest, I already have all the features I need; if I can't make good music with Hopkinton, I cannot make good music). I just want to work.
Hopkinton to be sure has some ****s and quirks on my setup, but over time (I'm still somewhat newbie-ish, having returned to the CW fold via X3e after 8 years or so away) I've learned workarounds, and that I can live with them pretty happily.
But since new features always bring new bugs, potentially I'm facing have to learn new workarounds each month, as well as seeing that some of my old ones no longer work. Just too much ongoing study for me. So here I am for now.
If I am to renew next July, I will not need to see any new features, but I will need to see at least one pretty darn stabilised release, so that I can have something which genuinely offers something less buggy than Hopkinton. And I would need to see it two or three months before July so that I can see for myself how it behaves on my setup, something which no one else can tell me.
(Anyone tempted to say, "Only a small minority of people have problems, you should be fine" -- just back the heck off -- I've got a pitchfork ;-) .... No really, Murphy's Law seems to have been written with me in mind, I'm too often in such "small minorities" to take any comfort, my eyes don't lie etc. so don't even start please.)
Moreover, I take serious issue with the (I'm paraphrasing, not quoting, Doktor A and many others here) "Upgrade not working for you? No problem, you can always roll right back" claim.
"You can always roll right back" -- ok, yes. The time spent downloading, installing and if need be rolling back a version is relatively trivial, yes, and the Command Center is a great addition to ease the way.
But "No problem" -- hold on there.
For me, bugs don't usually announce themselves upon application launch, unless it's one version not loading or playing a file created in a prior version.
Rather, for me, bugs usually emerge over time. Often they only pop out of obscure nooks and crannies of the software when you are deep within a project.
So.. what happens when something is amiss in a new version of Sonar? We know the drill … we down tools, stoically scrub up, suit up, go into troubleshooting mode ... and you know, sometimes it takes a fair bit of time and thought just to best design the testing, i.e. just what should I be toggling of / on individually to try to isolate the issue.
Anyway, you check numerous states of the project in that version of Sonar. Is it this song? You test other songs in that version of Sonar.
Still no joy? Make a thermos of coffee and settle in, lads, let's move now to horizontal analysis, i.e. comparing our results with what happens when we now follow the same debugging steps in the last "safe" version of Sonar. Potentially doubling the number of steps.
It can become a fully-fledged forensic chore. It completely squats on your playtime. (Thank goodness I'm only a hobbyist – if I were doing this for a client, under time constraints, I'd be one Nervous Nellie.) And as it always seems to be, you find the problem the last place you look.
So it can take a fair – often nontrivial – time to diagnose whether the culprit is even the new Sonar version or not.
"No problem"? If you are happy to value my time at 0, yeah, ok. I see it differently.
Even if you dismiss the above, then ... what happens, say, if you, tempted by Sonar's latest new routing features (patch points etc.), decide to use them extensively in a new project (there to be used, right?), only to find, once you are potentially many hours deep into it, that something else in the latest Sonar has a bug which requires you to roll back to a Sonar version which pre-dates patch points?
Where is your god now?