Official Sonar X2 Bug List?

Check the ReadMe file that comes with Sonar. 

+1. I think, if anything, when you submit a bug, the result should give you a few similarly reported bugs to see if yours fits into that category. I realize that this seems to admit acknowledgement by CW, but it doesn't have to signify that "yes, this is a known bug" by CW or anyone, other than it has been reported. This is really no different than a Tech Support agent identifying such a cursident.

Every time I have submitted a report with clearly outlined steps to allow cakewalk to repeat the issue I have received conformation that it has been submitted to development. I really don't understand why more information than that is needed. The best reason I know for submitting a bug report that has already been submitted is work to be done on issues often out weighs the manpower and time available to perform them. Work is often prioritized and either the designer will decide which issue is to be addressed first or use some form of input to make these decisions. In the case of software issues sometimes the magnitude of reports received on a given issue are used as an aid to set up prioritization.

rabeach
Every time I have submitted a report with clearly outlined steps to allow cakewalk to repeat the issue I have received conformation that it has been submitted to development. I really don't understand why more information than that is needed. The best reason I know for submitting a bug report that has already been submitted is work to be done on issues often out weighs the manpower and time available to perform them. Work is often prioritized and either the designer will decide which issue is to be addressed first or use some form of input to make these decisions. In the case of software issues sometimes the magnitude of reports received on a given issue are used as an aid to set up prioritization.

I think any type of feedback you can provide at least assures the customer that their issue has been noted.  I like a priority assigned to them as well, and even an ETA for fixes would be a good idea, but not always easy to implement or know.  You have to like the way Reaper does it.  Most companies would not go this far, but I do admire those that are willing to take these kinds of steps to address customer issues.  I did put in the survey response that I think Cakewalk could get MUCH better in this regard.

BretB
I am sure there is a list that would only be known by Cakewalk software engineering and management.  I would not expect a company to openly publish such a list to the general public.  Submitting a report would not be a waste of time however because the more faults they receive that are similar would tend to move that problem up the priority list.
 
A employer once told me "never tell a client that you have sh$*&% in your pants".  That doesn't mean that you are not working hard to correct the problem.

I agree with this, but I have to say, the communities in general, and the ways of doing business have changed dramatically. In modern times, those who hide are not trustworthy. Silence is no longer golden (we left the Gold standard behind in the 40's, remember? heh).
 
Apple Corp. uses secrecy and silence to create a huge bang when releasing new products, and they don't speak much on bugs. BUT, what they do right is offer updates, routinely. When you release small updates it's much easier to get feedback and community testing before proceeding to the next update. Before you know it, when you'd normally send out a whole new install (X2b,c,d,e etc) all the little updates can be rolled up into that. But now you've not only tested these updates internally. You've let your users, the ones who more likely will break the product, to test additionally for you.
 
Transparency is modern. What if we tried this: Let's create a new entity of community users that can be responsible for monitoring this board, who have signed an NDA, but most importantly are privately communicated with by Cakewalk to validate or invalidate specific issues, concerns, or cursidents. We can call these escalation people "sentinels". In this case, when someone posts on the forum, they have an issue, the sentinels can review it, and try to work with the individual before anyone at Cakewalk is involved. If the Sentinel validates the concern, possible bug, or just sees a collecting frustration among users, she can escalate this to Cakewalk at her discretion. Cakewalk knows that the sentinel has been briefed and understands that escalating needless issues may lose privileges to Cakewalk, so that any issues escalated are deemed important.
 
This is just one idea, but it helps clear a reasonable path up the food-chain, so that bugs that otherwise go unreported don't stow themselves away in the next release, lying dormant for some unsuspecting user, only to have it later be determined to be an actual bug that was grossly overlooked.
 
I also believe that 50% or more if the issues people have with the product aren't duplicated during a Support call, or it happens at 3AM, when many studios are still very alive and working.

Too, if you report a bug, but get no communications back, you tend to lose interest to report more of them, simply because you have no gauge as to whether you're heard by deaf-ears, or your submission is genuinely looked into. So, there's no incentive. That's why I ALWAYS come to the forum first, and usually don't go any further. I'm always hoping someone else will submit it because they had experienced the same quirk I found.
 
I just don't have any interest in submitting a bug unless I get someone to attempt to duplicate it. That sounds backwards, since I could call support, but when do you normally experience a cursident? Late at night while tracking when support is closed.