Post-membership bug blues

So, my membership came to an end, and with it, the chance of me seeing several bugs fixed. In the space of 10 minutes yesterday, I hit the delete time bug (not even any sort of esoteric case - it was just refusing to delete the gap and only slid one track over, leaving the rest all in place) and the click-to-open-drum-mapped-clip bug (submitted a month ago, not even looked at by Cakewalk yet). Those two probably wasted a good 30 minutes of my time as I had to work around them, scrolling around every time I wanted to edit drums, fighting with the lasso tool and the various selection keypresses to try and get data to move one measure to the left (before manually fixing up all the markers... and the envelopes...and the tempo change... etc). I also saw the old problem where the snap offset gets moved around wrongly because I had the audacity to slip-edit the same audio file in 2 different ways, though luckily I didn't need to move the clips after that point so I can just pretend there's nothing wrong.
 
In the past, there was the chance that if enough people complained, a patch would be released.
Now, I have no choice - pay up, or just accept these bugs, forever.
 
I don't begrudge the Cakewalk people getting a more steady flow of income for their work. But I do somewhat resent paying to essentially be a beta tester for several months, often hitting severe roadblocks in the process (drum maps dropping notes, drum maps breaking entirely, automation getting somehow added without my intervention (and showing up other bugs in the process!), etc), to reach the end and still not have a particularly polished product. Sure, I have a bunch of new toys that I don't use (drum replacer, vocalsync, prochannel modules) but if I'd been told 12 months ago that this is what I'd expect, I don't know if I'd have bothered migrating from X3. Instead, I reached the end of February feeling like I was being held to ransom - pay up now, or risk never seeing these old bugs fixed.
 
Here's what I'd like to see, as some sort of goodwill from Cakewalk; backport fixes into old releases and have them available via the CCC even for people whose membership has lapsed. I've paid for this product and feel that it should work properly. I shouldn't have to keep throwing money in, hoping to be thrown a bug-fix bone in return.

dcumpian
While I do agree with the sentiment, the logistics of back porting a bug fix into older versions seems like it would be daunting, as each version may have different code changes that would make a single fix unworkable.

Some do, some don't. It's a common situation in software development and there's a standard procedure to follow (consolidate the fix in a few changesets, preferably one, then compare it with the code you want to fix - sometimes it can be applied automatically, sometimes it can be applied with a few minor tweaks, and sometimes it's impossible to apply.)
 

To be honest, I'm not sure it is really any different than any other DAW. If a version is not bug free when the next paid upgrade drops

Let's just say that reducing the paid upgrade cycle to monthly shouldn't get developers off the hook when it comes to the responsibility to deliver working software.
 

I hope you choose to stick around, your input is certainly valuable.

 
Thanks. I'm sure I'll be here off and on, until I can afford to buy a different DAW. But if there are no fixes for non-members then there's no point me reporting bugs either.

Bob, did you ever try working with Cakewalk Tech Support on that issue or systematically disabling plugins to see what might not be playing nice with Manchester+?
 
Based on the fact that not a single other user has reported that memory usage issue to my knowledge it seems clear there's an interoperability issue with that particular project and/or you system hardware most users will never encounter. And it won't get fixed if you don't help the Bakers identify the cause.
 

It can be really difficult to fix bugs. I am not at all sure that it becomes easier when you are trying to add new features every month instead of every year or so. In any case i can suggest a simpler solution to the problem of having users waste a lot of time trying to get a feature to work when it will never do so without a bug fix. Fix the documentation. When a bug is confirmed, PROMPTLY change the online and printed documentation to say the procedure explained for this feature does not work as written or does not work under known conditions. A known workaround is... or There is no known workaround at this time. The first thing most users do when the find a problem is to look up how it should work. Then they carefully read the documentation confirm that they are doing it right, try it several times, recheck every setting they can think of, revert to an earlier version to see if it worked there, reinstall Sonar, reinstall windows, some will find their way here to see if anyone else can get it to work as intended, pound their heads on the desk, curse the gods, and finally wait until phone support opens to be told that it is a known issue and there is no solution at this time. Even though it will undoubtedly scare away new users to see a clear acknowledgement in the documentation that there are bugs in the software, it would be far better to interrupt this process at the beginning, rather than build resentment and frustration that motivates users to not only drop their membership but bad mouth the product as widely as they can. At the very least there should be an easily accessed, easily searched, and professionally and consistently written knowledge base for known problems MAINTAINED BY THE COMPANY rather than relegated to this difficult to search and often contradictory user help forum system. I love the forum, and for oddball and unconfirmable issues it can be very useful. God knows I have learned a great deal about Sonar here, but it is not the most efficient way to solve a problem, and certainly not for a new user who has found that the documentation is just wrong. 

Well the ideal situation is you have two codebases more or less: A development one and a stable one. You have a version that gets the latest greatest features, and another that is just bug fixes. Every so often, the stable version is moved up to a point in the development line. It works well, and you see it in things like operating systems and so on. The problem is you need a lot of people to make it happen, since you have two separate codebases to maintain (or more, depending on how you do it). It does not sound like Cakewalk has the people to make that happen.
 
Personally I wish there was a greater bias towards bug fixes and stability and less towards new features, but people get complain-y when they feel like they "aren't getting anything" for a maintenance fee.

I just finished making a homemade greeting card in an older version of Coreldraw.
I have gotten used to do my creating and editing with plenty of ctrl S alone the way.
I feel the same way about Sonar. Love the program (want staff view/ notation fixes- yes my gripe after all these years of no love) but I agree Sonar is like my cats, finicky

The point of my post is not that Sonar is not,or should be made more, stable or predictable. I assume those fixes will be difficult, time consuming and expensive. The point is that through the simple magic of changing a few paragraphs or screenshots in the help file, a bug can instantly be transformed into an absent feature. Hell, if you want the buying public to think the program is bug free, just delete all mention of the ability to do X using the well documented method that does not work as described. Providing relatively clear instructions that do not work for most users is much worse from a customer relations standpoint than just not saying you can do X at all. This is not a style issue. It is a usability issue at least as important to the frustrated user tearing his hair at midnight as the ability to make adjustments using a cartoon version of a mixer channel strip. It is a customer relations issue at least as important as offering telephone support for technical problems. Hire a technical writer who is familiar with the program or pay him to get familiar, and task him with editing the monthly updates of the help file to assure that following the directions does not lead to frustration. Instead the documentation continues to give incorrect instructions, that persist after they have been identified, and bug reports are apparently closely guarded secrets from the user base at large, and are only officially publicized when there is a fix in the next release. Sonar is not the buggiest program I have used, or the most frustrating, but only because I have used a lot of open source community product. From that community we have come to expect abysmal documentation and help limited to cryptic comments in the source code. 
 
The knowledge base issue is more difficult and expensive, but it could pay for itself in decreased use of telephone support. Microsoft reportedly developed its very useful knowledge base primarily to assist its support personnel, and now it serves as the primary source for most users who do not want to pay per incident for simple problems. In addition a hyperlink to the appropriate knowledge base article from within the help system could save the help system editor a lot of duplicate writing.

FanCake
I doubt it would save much money as from my experience - customers do not want to read documentation.

 
Whenever someone comes up to me and says "I read your manual on [product name]," I always reply "So you're the one!! I just knew someone out there reads manuals!" I used to think it was a joke but I'm not so sure.
 
One time I was consulting to a hardware company and said they really needed to write better manuals. They were puzzled. "Why? The customer has already bought the unit."
 
It would be interesting to have an alternate, crowd-sourced version of manuals online where people could make corrections and add tips, as long as any additions were hidden until someone from the company could verify they were correct. 
 
[Note to FanCake: I've tried to send you a PM saying you were right in the locked thread, but I guess you don't have enough posts to receive them yet. Anyway, just wanted you to know.]

 

Anderton 
Whenever someone comes up to me and says "I read your manual on [product name]," I always reply "So you're the one!! I just knew someone out there reads manuals!" I used to think it was a joke but I'm not so sure.

I will never understand the logic behind not reading a manual.  The investment in reading time is returned many times over in productivity. 
 

Anderton 
One time I was consulting to a hardware company and said they really needed to write better manuals. They were puzzled. "Why? The customer has already bought the unit."

 
This attitude seems to be disturbingly common.  Many companies now don't even bother to write manuals. A close to home example is that there is no manual for Melodyne 4 Studio (or any other version 4 I would hazard to guess). To this day (3 years after release) there is no manual to download on the Behringer website for their Compact and Rack versions of the X32 Digital consoles,  both reasonably complicated beasts that operate quite differently to the full sized model. What came first -  the laziness of the consumer or the indifference of the company? 
 
On the upside,  I believe Sonars documentation is pretty darn good.  The sheer size of it often puts people off,  but this is largely due to repeated information in order for users to be able to find the answer they need in whatever context they are working without having to read the entire manual.
 
Slartabartfasts suggestion of a database of known bugs is an excellent one.  Trying to find out if a problem has been reported is all but impossible,  let alone official verification.  Not holding my breath on this one though as it's a tad awkward from a marketing perspective:)
 
A user based online manual where bugs/workarounds could be recorded is an interesting idea,  but in practice it could be an unruly beast.  A quick look over all the posts on this forum and even submitted problem reports shows that whilst there certainly are plenty of verifiable issues,  more often than not what people perceive as bugs turn out to be human error or operational unfamiliarity.  Editing and maintaining this behemoth could be quite a task.  
 
 

Kylotan
 
Thanks. I'm sure I'll be here off and on, until I can afford to buy a different DAW. But if there are no fixes for non-members then there's no point me reporting bugs either.

As you have voiced interest in Studio One previously, I just thought I would tell you that they offer a 'Cross Grade' pricing from users of other DAW's, I took advantage of this back around the time Studio One 3 was released, and to be honest I haven't looked back. Solid as a rock, not one single crash in the ensuing 8 or so months, LITERALLY not one. Awesome features (for me anyway), and no more of the not knowing what is going to be broken next month that worked previous;y, every month, month after month. Sure you can roll back, but is that really the point? I have tended to see the roll back feature through different eye's as time has passed, and tend to agree with others who seem to think that it is almost like an open license to release software that is not quite ready for prime time, because hey, you can always roll back, and like you mentioned yourself it is pretty much like being an unpaid Beta tester, I can't deny that feeling was there.
 
The change to Studio One was quite painless, a bit of time to learn your way around certain features and methods, but nothing really, I felt at home almost instantly and you just learn the other stuff as you go, but it was a breeze. I can get things done much quicker, and I have confidence in updating, and don't have that monthly lottery when update time comes around. Been using Sonar since Pro Audio days, left for a while at the start of the X series, came back at X3, moving to Studio One was the best move I have made in a long time.

Gone!!
 
As you have voiced interest in Studio One previously, I just thought I would tell you that they offer a 'Cross Grade' pricing from users of other DAW's, I took advantage of this back around the time Studio One 3 was released, and to be honest I haven't looked back. Solid as a rock, not one single crash in the ensuing 8 or so months, LITERALLY not one. Awesome features (for me anyway), and no more of the not knowing what is going to be broken next month that worked previous;y, every month, month after month. Sure you can roll back, but is that really the point? I have tended to see the roll back feature through different eye's as time has passed, and tend to agree with others who seem to think that it is almost like an open license to release software that is not quite ready for prime time, because hey, you can always roll back, and like you mentioned yourself it is pretty much like being an unpaid Beta tester, I can't deny that feeling was there.
 
The change to Studio One was quite painless, a bit of time to learn your way around certain features and methods, but nothing really, I felt at home almost instantly and you just learn the other stuff as you go, but it was a breeze. I can get things done much quicker, and I have confidence in updating, and don't have that monthly lottery when update time comes around. Been using Sonar since Pro Audio days, left for a while at the start of the X series, came back at X3, moving to Studio One was the best move I have made in a long time.

The trouble with Studio One seems to be that people are easily distracted from it by an insatiable desire to haunt the Sonar forum and post about Studio One:)

I don't understand what the point is of reporting bugs in X3 or any version other than the current release as it's the only one going to get fixed.

Sorry misunderstood your first post. Thought you were still on X3. My bad.

Anderton

tenfoot
 
The trouble with Studio One seems to be that people are easily distracted from it by an insatiable desire to haunt the Sonar forum and post about Studio One:)

I'm not sure there are that many rude Studio One users. A lot of posts regarding it are made by the same people, which includes some who have alts (e.g., Gone!! used to post as jih64). 

Yes indeed Craig -  my comment was entirely directed at the ironically named though ever present Gone!!.  I am sure the vast majority of Studio One users are almost as pleasant and polite as Sonar fans😊