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.

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.
 
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, you are generally forced to buy the upgrade for any bug fixes (and the privilege of finding newly added ones).
 
I hope you choose to stick around, your input is certainly valuable.
 
Regards,
Dan

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.

I can relate, except I renewed.  M looked great at first.  Then after getting pretty far into a project I started getting errors where Sonar quits responding, consumes all of my free ram, then slowly releases it all again.  At this point it becomes responsive again.  The problem is that this cycle can take 20 minutes or more.  Newburyport still has the same problem.  I ended up rolling back to Lexington, which was stable enough with the same project for me to get the tracks exported so I could begin the process of reconstructing the project in a different DAW.
 
I don't dare start another project in a version of Sonar later than Lexington, but really why bother?  So I've basically moved to the other DAW for the time being.  I'm paid up with Sonar for another year, so I'll check back a few releases down the road and see if things have improved.  This has been a real confidence shaker for me.

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.
 

I feel ya but FWIW I actually got some extremely bothersome bugs and desing flaws corrected this year (actually pretty early on too). Things that were really screwing up my workflow particularly when editing which probably accounts for 40-50% of my time at the DAW as well as other things that were making some of the tools I needed (and bought Sonar for in the first place) unuseable.
 
Unfortunately I think it's simply a matter of what areas/features/workflows people use regularly. The problems these days seem to be little finicky ones constrained to specific areas of the program and/or only incurred when performing specific tasks. So 95% of users don't get affected but the for the 5% who do it's brutal. I've encountered quite a few of these in my travels around Sonar but fortunately, in most cases, they weren't the type of thing I'd be doing day in and day out so I either find a workaround or just not bother (I usually find these things when I'm trying get fancy with something).
 
I'm not entirely lucky though. There are many automation tasks I can't do properly because of a plethora of dumb design limitations and just totally obscure bugs. I essentially can't use automation at all how I'd like to and am restricted to extremely basic brute force tactics.
 
In fact it is SO problematic and awkward I've actually just resigned myself to setting up entirely new tracks, cutting and pasting the sections I want effected into them then setting up the effects and settings there instead of automating the changes in the original track(s) as I would like to. It's very frustrating.
 
I've been learning how to use the "Cheap" DAW as a companion for Sonar to work around some of the things Sonar can't do or doesn't do as well but since I heavily rely on Prochannel effects using it for automation is out of the question if I intend to mix in Sonar... which I feel is it's biggest strength over the competition. The alternative is to use the VSTs I have installed in the other DAW but I don't like them as much and I really despise the mixing workflow in pretty much ALL the DAWs I've tried compared to Sonar.
 
Meh... just as long as we're kvetching. lol
 
Sorry.

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. 

slartabartfastthere should be an easily accessed, easily searched, and professionally and consistently written knowledge base for known problems MAINTAINED BY THE COMPANY

this has been requested forever, the closest we've ever gotten is the problem reports forum; there is no "officially recognised" "known issues" list, nor do i ever expect to see one, it's just not their style :-(

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 had the same idea when I have started to use Sonar. And I have proposed the same. But I guess that will never happened. As you have mentioned, what potentially users will think observing an "official" list of bugs which was found and confirmed 10 years ago and are still there?
From my perspective, Sonar is more stable these days compare to what it was at X1 phase. Apart from that, it was and still is one of the most buggy program I have used in my life. But "Experts" are claiming Sonar is not worse then other DAWs, so I do not even try to move. May be that is a mistake, may be not. Time will show.