Kylotan,
 
There was once a time where I was very disgruntled on this forum.
for a short time I was on a mission to just blast anything I could find wrong with Sonar.
I argued with users (who I thought were being homers / Fanboi's).
Then I took a break from this forum and started using another DAW.
 
I started using Pro Tools. Tried Reaper, Studio One and Cubase.
What I finally began to realize was, these DAW's had their Quirks / bugs as well.
Some of them did exactly what I wanted, some of them did not.
Some had bugs in areas where the others did not.
 
I put my hands in front of me and created an imaginary scale and weighed out the pro's and con's
of each DAW. What I came to understand was Sonar fit my needs best.
Maybe not the best DAW...But it was the DAW that fit my needs.
 
Now back to being miserable.
I decided that if I was going to come back to this forum (which I honestly believe is one of the best support forums on the web) I was going to try and stop complaining and try to be more constructive in my comments.
(for some reason it seems like no one listens when we complain, only when we are constructive)
and that's just what I did. I also tried to help others as much as possible.
This way...if I do complain once in a great while...people will understand its not in a negative way.
 
I would go about the proper procedure and file a report on those bugs with as much info as possible.
the more detailed the better. I can see by some of your threads. you have outlined and detailed things very nicely.
that's about all you can do.
maybe your different from me but like I said above. when I stopped using sonar, I missed it.
Good luck.
 

i read Kylotan as being frustrated with the "proper procedure" and that seems exacerbated by the responses here...
only anderton responded directly that 1 was fixed, but what about the others?
no-one tried to reproduce them, even though his links all contain the info required (info that is repeatedly requested on the forum for troubleshooting) it just got off-topic as per usual...
i can understand his ire
 

chuckebaby
 
Maybe not the best DAW...But it was the DAW that fit my needs.
 

This is the same reason that I stay with Sonar.
 

Kylotan
3) Unnecessary snap offsets being added in to clips

i also get weird results following your recipe for this one

I really think it all comes down to priorities. Some bugs and "rough edges" will affect a large number of users. Some will affect only a few under rare circumstances. If the latter is an important part of a particular workflow, then it becomes of massive importance to a few but remains unimportant to most.
 
Cakewalk has made it clear that the company is committed to fixing as many long-standing issues as possible, above and beyond the fixes listed each month in the eZine. I can't disagree with the premise that ripple editing, plug-in load balancing, and streamlining the comping functionality are of significant importance to the majority of SONAR users. Conversely, an overhaul of drum maps affects only those who use MIDI to create drum parts, and furthermore, actually use drum maps (I create drum parts with MIDI, but use the regular note mapping except when working with the Step Sequencer). While the number of people who fit this category may not be insignificant, I'm sure it's nowhere near as big as those who want to be able to run more plug-ins, insert and delete measures and move sections around easily, and have comping live up to its full potential.
 
I agree that people should use the program that fits their needs best because there is no one "best" program, or everyone would use that. As a software reviewer for decades, I can run sessions on all the major DAWs for both Mac and Windows (except Reaper; I just didn't have good chemistry with it). They all have their quirks, limitations, and workflow issues. If you go to the forums for any program, you would get the impression that none of them work, ever. 
 
So, I use SONAR because it fits my needs best. I'm not interested in DAWs per se. I am interested in completing a variety of mission-critical projects quickly and efficiently, on a regular basis. My DAW of choice flows from that premise. I do not choose a DAW with the hope of making it match my needs, because that approach will rarely be successful.
 
 
 

i think if the feedback loop looped all the way back users might not get so frustrated - there does seem to be a disconnect between the external bug reporter that leaves reported issues as "new" even though they've been fixed... i assume the externally reported bugs are pulled into an internal system for proper triage etc, so why not at least let users know they're not going to be fixed/prioritised? better to know bad news than no news at all (or is it?)

pwalpwal
i think if the feedback loop looped all the way back users might not get so frustrated - there does seem to be a disconnect between the external bug reporter that leaves reported issues as "new" even though they've been fixed... i assume the externally reported bugs are pulled into an internal system for proper triage etc, so why not at least let users know they're not going to be fixed/prioritised? better to know bad news than no news at all (or is it?)

There are lots of people who report bugs. Sorting through all those just to find the ones that really are bugs, are reproducible, may become irrelevant over time because of other changes of fixes being made to the program, etc. is by itself a time-consuming process. As to "why not at least let users know they're not going to be fixed/prioritized," that's because it's impossible to predict which ones will be fixed and which ones won't.
 
The purpose of creating bug reports is to give Cakewalk an array of possible issues. Once in possession of this data, Cakewalk can start making decisions about the general direction that fixing those issues will take. Many times fixing one bug has also fixed another bug that was not specifically targeted for fixing. 
 
I think the most important aspect of bug fixing is the part where users provide data to create a pool of possible bugs, and that Cakewalk interacting with users and updating them on which bugs are being fixed, aren't being fixed, may be fixed, may not be fixed, etc. is less important. Software is in many ways too abstract to lend itself to that kind of linear approach to problem-solving. Often problems are attacked in parallel. The bottom line is effort spent around the periphery of bug fixing is not time spent on bug fixing itself, and again, Cakewalk has to set its priorities. I think the desire to maximize the number of bug fixes is a priority that's in alignment with most users.

Anderton
I think the most important aspect of bug fixing is the part where users provide data to create a pool of possible bugs, and that Cakewalk interacting with users and updating them on which bugs are being fixed, aren't being fixed, may be fixed, may not be fixed, etc. is less importan

i disagree with this - letting the user know one way or the other is important, otherwise, as we see, users become frustrated and then despondent, and stop reporting them
 
how will the proposed new feedback portal improve this?

So, I'm assuming the current answer is, "Yes, No, No, No, Maybe, No"?

John
There are no bug free DAWs. 

This attitude does nothing but breed complacency. If you were on my QA team you'd be on your way to a new assignment in the mail room.