I am rather confused by that. Fixing bugs does not make a better product? Ironically, no one seems to consider the man hours spent by users writing these reports.

mettelus
I am rather confused by that. Fixing bugs does not make a better product? Ironically, no one seems to consider the man hours spent by users writing these reports.

I'm not sure that was what was said. Fixing bugs does make a better product and I don't think anyone would dispute that. Its the following up with reporting back that might be unproductive. If its fixed does CW really need to inform the reporting user that it was fixed? My understanding is they list it being fixed in a file like the eZine. 

mettelus
I am rather confused by that. Fixing bugs does not make a better product?

 
Of course it does.
 

Ironically, no one seems to consider the man hours spent by users writing these reports.

Presumably the people who do so write those reports to help improve the program. Then the question becomes which will improve the program more, spending time fixing the bugs, or spending time providing status and feedback reports to the people submitting the bugs. In an ideal world, there would be sufficient resources to do both. Given that this is not an ideal world, priorities have to be set. I can certainly understand that a person who submitted a report would get frustrated if there was not sufficient acknowledgement of that particular report, but if there's a bug experienced by multiple people, fixing it would reduce frustration for a greater number of users. I do know that people monitor the fixes in the eZine and are gratified when they see something they reported, or that bothered them, is fixed.
 
I don't know whether the feedback portal will streamline this process or not. 

Klyotan,
 
I'll answer your question directly:
 
I read your links with interest, and I have never run into any of the issues you post about here (including the takelane issue you so thoughtfully provided a video of.) The reason I haven't for most of them is probably because my workflow is different from yours, so I haven't run into those specific defects or I haven't set up the conditions for them to show their ugly little faces, but I do sympathize with your frustration. I know you don't want to hear about suggested alterations to your workflow, so I'll move right along here.
 
You're entitled to feel whatever you want, and you're entitled to express any opinion or make any assertion you feel like making here. I fully support this exercise in disgruntlement exposition, and I completely understand if you decide to pack Sonar away and move along to another product. We do what we gotta do to make things work.
 
On the other hand, no one is required to agree with you or anybody else here, and I find it a bit humorous that so many folks post things and then get upset when people challenge their assertions. 
 
As a software developer, you're no doubt aware of how bug reports flow through organizations and how they decide to fix things. If you're a corporate developer, reporting status to your customer is an essential part of keeping the business running. As a commercial product developer where customers may number in the tens or hundreds of thousands, or even millions (in the case of companies like Apple, Google and Microsoft) closing the feedback loop is incredibly difficult. Nobody likes letting that kind of opportunity for customer communication go. 
 
As for the issues I do experience, I elect to read the release notes and check to see if the most impactful issues are still there. I don't want to tell you how to manage that process, but if you do that, you don't need to post questions like the one you posed here. Just skip to the part where you create a fun Cakewalk-bashing-rage-quit thread. [Update: This last comment is supposed to be humorous and does not necessarily reflect my opinion of actual persons, either alive or dead.]
 
I sincerely hope you find something that works well for you!
 

Kylotan

chuckebaby
What ever the case, I hope your making good music and not letting this get in the way.

If only. Here's today's Take Lane bug wasting my time and interrupting my flow.

there are tack lane enhancements in the oven, when I don't know but if you look at cakewalk's main page "future updates" you can see what is planned:
Take Management & Comping Enhancements
http://www.cakewalk.com/Products/SONAR/Rolling-Updates#In-The-Oven
 
by the look of it, there are a lot of great updates in store. hope this helps.

90% of the time that tool works fine. 9% of the time it does something weird but manageable (like moving some of the adjacent clips but not others). And on that particular set of clips, it shifts the audio entirely. Who knows why? All I know is that it's unreliable and I sincerely hope they rip the logic out and completely replace it, for the sake of you guys who will be using this software in the future.

3) Unnecessary snap offsets being added in to clips
 
This bug came with Sonar 6 when SlipStretch editing (part of AudioSnap) was introduced.
(SnapOffset exists in Sonar 4 and probably earlier versions). The buggy interaction between the two evidently was never noticed.
 
It happens whenever a clip and it's audio content do not start at the same place and you then SlipStretch.
Usually this happens when you split a clip. All clips except the first will show this bug.
 
But for testing purposes, you can just go to any audio clip and move the audio around a bit by pressing Shift+Alt and then moving the contents of the clip with the mouse.
 
In the Inspector open the Clip properties and look at Snap Offset. It should be 0.
Now go to your clip, do a SlipStretch edit, and you will see that Snap Offset is at some non-zero value.
Sometimes the flag ends up outside of the clip. so it's best to look at the actual value.
 
Last year, brundlefly kindly gave of his time to help me track this down and I reported it under CWBRN-40003 and the Bakers pretty soon after that set the status to SUBMITTED TO DEVELOPMENT and there the matter rests.
 
My preferred workaround, non-destructive, is to select all affected clips and manually put their collective Snap Offset values back to 0. Annoying, but there you are.
 
If we can make it clear that several of us suffer under this bug (and, I suspect many more who cannot understand why Snap To Grid is not working as expected), then perhaps this bug will come to the attention of The Bakers.

Well, of the 14 bugs I reported over the past 4 years, 6 have indeed been resolved.
Admittedly, the last one was some time back. And this particular bug is still my biggest bugbear.
 
I'm still hopeful.
 
Squeaky wheels, oil and all that.