to be fair, tripecac said he was, and apologised for, "being squeaky" (as in "a squeaky wheel gets oiled") and his old bug still has status "new" which means it hasn't been reviewed or prioritised yet, so how does he get attention to it other than on the forum?
/fwiw

I guess he'll just have to wait Paul.
 
If that's not good enough (for him) then he has a choice to make.

I have reported approx. 12-15 bugs, some going back years.
 
They are all with reproduction recipe, most with other members saying they can also reproduce them. I always include links to the relevant threads in the problem report.
 
Most are set to "New" and have not been fixed.
Some are still "New" but HAVE been fixed.
One is set to "In Development" and has been for over a year, maybe two years now. Not fixed.
One was set to "As Designed" but nevertheless was fixed.
 
You just cannot tell.

Anderton
Bugs are in a queue. The order of the queue depends on multiple factors. The primary one is if large numbers of users are affected and it causes crashes or serious operational problem.

I understand OP question is exactly what you write here. With the current system, users need a Crystal Ball to know the bug is really queued. I do not propose to inform the user about the priority or progress, but at least 2 more statuses: "Queued" and "Fixed" could be helpful.
 

That bug you were complaining about that had something to do with track folders and inserting a track going outside of it was fixed. It's probably best to appreciate that some of the bug that affect you are being fixed, rather that being unhappy that not that all of them aren't, and get back to making music.

As a developer, I normally appreciate when someone find my bug. And keep the person informed about fixing, obviously not waiting for appreciation (that was my bug which has disturbed someone).
 
Cakewalk in fact behave the same way when they have such opportunity. It is Bug Submission System and Bug Tracking System interconnection which need some attention.
 
Also if everyone will start to check either every new version solve some bugs from the (usually long) list, people will have no time to make music
 

I can well imagine it becomes a problem when many people report different bugs with the same fundamental cause.
 
Who's gonna pay someone to go through the whole list and examine each bug, setting the status as appropriate?
 
Yes, I have written an issue tracking system.

bitman
Craig, Just let people be people please.

I was hoping that what I wrote would explain the process, and the OP would understand that "refreshing" a bug is a waste of his time that could be used to make music. Although I agree 100% that it would be great if the bug-fixing process was more transparent, given the resources available to fix bugs, taking the time to make the process more transparent would paradoxically take away resources from actually fixing the bugs.
 
I understand that many people here do not work with a software company, and so they have no frame of reference for the mechanics of how processes work. I certainly didn't until I got involved with Cakewalk on a level other than being a user. I try to communicate what I've learned in order to help de-mystify these processes.
 

I was hoping that what I wrote would explain the process, and the OP would understand that

 
Sorry, but I'm not after explanations and excuses and accusations of ignorance.  I am after bug fixes.  That is why I am squeaking.
 
Someone in another topic said that he had to submit problem reports multiple times in order to finally get attention from "the bakers" (whose response time often makes them seem more like "the baked").  For that user, spamming via the Problem Report form is what worked.
 
Does anyone else have that experience?  Is resorting to sending multiple problem reports paraphrasing the same bug likely to decrease the baked's response time?
 

As a developer, I normally appreciate when someone find my bug. And keep the person informed about fixing, obviously not waiting for appreciation (that was my bug which has disturbed someone

 
I normally appreciate when testers find my bugs.  Not so much when end users find them, although it is gratifying to fix 'em for a "live audience" rather than just the QA team.
 
What I find on this darling forum is that whenever I post a bug or "I am missing this feature from 8.5.3" post, the forum's first general reaction is to point a finger back at me and say "it must be your computer" or "well, here is a multi-step workaround and if you are not content to accept the workaround rather than a fix then you are a mulish griping idiot".
 
Post a bug to Cakewalk.  Get ignored.
Post a bug to the forum.  Get insulted.
 
Not that I care about getting insulted.  Obviously.  I just care about getting my bleeping bugs fixed!

Tripecac

I was hoping that what I wrote would explain the process, and the OP would understand that

 
Someone in another topic said that he had to submit problem reports multiple times in order to finally get attention from "the bakers" (whose response time often makes them seem more like "the baked").  For that user, spamming via the Problem Report form is what worked.

Hi, I think this was me.  For clarity, I meant to convey that I submitted a second tech support email if I didn't receive a response to the first one. I haven't submitted bug reports before, so can't comment on that objectively.  Apologies for any confusion. 
 
 

My experience is unrelated to Cakewalk or any music software, but I used to sit in on sustaining meetings on some internal corporate software, I was there to argue the case for bugs or enhancements affecting my domain to be pushed up the list of priorities.  Sustaining and development were separate, development was totally dedicated to the next product unless a critical issue was detected.
 
It’s an insight into the way things have to work. It’s frustrating when you see your issues bypassed “for the greater good” but with the reasoning exposed one understands the business case.  In reality one knew most of the issues would never rise up the list far enough to be addressed.
 
The other thing was how much time was actually needed to address what seemed to the end user to be simple but annoying bugs. The bottom line was generally, if there is a work around it will never be fixed.
 
As much as we would like software companies to fix everything, I fear in the real world the way it has to work is similar to what I have outlined.

Tripecac

I was hoping that what I wrote would explain the process, and the OP would understand that

 
Sorry, but I'm not after explanations and excuses and accusations of ignorance.  I am after bug fixes.  That is why I am squeaking.

I'm simply describing what I see as the reality of the situation, which is that if you just want bugs fixed, squeaking will make little, if any, difference. I don't want to see you wasting your time so I gave some reasons as to why I thought you were doing so with your approach.
 
If all you truly care about is seeing bugs fixed, I recommend that whenever you see someone else mention a bug you want fixed, PM them and encourage them to submit a bug report. Multiple people reporting one bug one time each will have much more weight than one person reporting one bug multiple times.
 
Remember the bug where the VX-64 and some other plug-ins could cause a massive pop on some occasions? I brought it up with Cakewalk and nothing happened. But there were other comments in the forum about the same problem. I copied the comments and sent them to CW, who then realized this was a significant problem affecting multiple users.
 
I then started a thread about it, and CW received enough information from users that they were able to isolate the source of the problem, reproduce it (not easy with an intermittent issue that occurs rarely), and fix it. I can guarantee that just me squeaking would not have fixed that bug, because it didn't. However ultimately if after gathering data on how companies handle bugs you believe squeaking will work better than what I recommend, then go ahead and squeak.