No, I won't contact tech support. (well, yes, I did)

One of the really wonderful things about CW are its support people. I have never in all these years had a problem interacting with them. Its always been a pleasant time spent with them. I find this thread obnoxious in its ridiculous assumptions.   

yevster
Having been a beta tester for three years, I would submit that the accusation of "not wanting to hep them track down and fix a bug" doesn't quite apply :) However, the effort that is expected of paying customers is, ironically, much greater than that which is expected of beta testers. The bug submission form, which requires you to fill a separate box for every step and makes editing difficult, is unnecessarily painful. If, on top of that, Cakewalk wants me to spend time and money on phone calls so that they can fix their software - I hope I can be forgiven for finding that a bit excessive.
 
I get it, Cakewalk is tragically understaffed and needs all the help it can get. But I bought their software out of self-interest, not altruism. It's bad enough that so much is broken after two patches. It's worse that paying customers are expected to go out of their way to help fix things.

Yevster, I just took a look at your project and your report.
 
It consisted of:
 
MIDI Clip copied from another track is silentDescription:

1. Open attached project.
2. Play from now time (or around bar 74)

Expected Results:The unmuted clip on track 20 should play audibly.Actual Results:The clip on track 20 does not play. However, any other clip recorded onto that track or any MIDI input set to the track will play just fine.
 
 
The take you were having a problem with had a rogue controller envelope of Velocity = 0. Once the clip was bounced it behaved as expected. In this case, calling support may have helped you and without the public humiliation. There was very little in that report to really give us anything to go on.

EDIT: There may be something going on here in regards to Simple Instrument tracks+lanes+automation, and I'm investigating, but your report doesn't indicate anything about this fact.

Also, we'd like to refer you to the forum TOS:

TOSUnproductive trash talk will be met with criticism and possible disciplinary action including banishment. The same rules apply to trolling and/or posting topics specifically to provoke a negative response.

We'd argue that this topic wasn't posted to spur a positive response.

LynnI filled out a bug report recently regarding the Tape Emulator causing a 60 hz hum after the program was idle for a few hours.  I got an e-mail yesterday telling me to call tech support.  I just got off the phone with them, and the CW guy told me that they knew of the problem, but there was nothing I can do about it now.  He couldn't guarantee that it would be fixed in the next update or any thereafter

The 60hz hum issue should be getting fixed in the next point release. 

stevec
I'm curious... when something moves from a bug report to technical support, does it move to a different team within CW?
 

Short version:
Confirmed "bugs" move to QA & Dev. Tech Support can't fix those but they can help identify them.
"Non-bugs" move to Tech Support since they can help and they don't belong in QA and Dev's pile of things to do.
 
Long version:
 

There's some crosstalk between teams. Technically Seth is in Quality Assurance, I'm in Technical Support, and Noel is in Development, but all of us have access to the same tools if we really wanted to do each other's jobs (which sometimes we do... well... nobody does Noel's job... that would be bad ;)
 
The point of updating a CWBRN to "Contact Technical Support", other than just wanting to provide more direct assistance, is to get it out of the developers' queue though. Agents are FORCED to set a status to the report. They can't delete a case like you can delete an email (actually we can't delete emails either but that's besides the point). If the case doesn't belong or is incredibly vague, such as "where is my serial number" or "how do I record" or "I get crashes... fix it!" (yes we get these), then we update the status appropriately (versus just deleting the report). Updating the status allows us to build reports as well as auto-notify customers with instructions on the best course of action to get the proper type of assistance.
 
The Technical Support/Customer Service case management and Problem Report systems are completely independent of one another intentionally. One is a purchased solution, another is a home-brewed solution. We have a lot of custom built behavior with the Problem Reports (for example the way the Fault Reports come in and parse .dmp files automatically etc.). The entire system is built and maintained by Cakewalk staff. The people who dig into the problem reports try to keep the submissions as accurate as possible, which means pushing them to other teams when they don't belong or need further clarification.
 
In a perfect world all of this would be completely seamless. At the moment though, the systems are independent of one another which is why we reassign statuses. Two separate systems also allows us to understand what people are contacting us about more easily. The goal here isn't to be unhelpful to customers.  It's actually quite the opposite and has proven to be quite effective (versus how we used to manage things when I started which was basically just different email addresses for different teams). The request for steps in problem reports has improved our ability to help customers and now results in fewer back and forth questions (which ultimately wastes more of a customer's time then just providing steps of what is happening).
 
I do have some improvements planned to the system overall, but at the moment this is how the systems are set up. I love when people make suggestions, but when it comes to demands please remember we're a small team and actually have some pretty advanced tools that even some major corporations don't have. We're all working hard here and are trying to manage a lot.
 
By the way, if someone in technical support identifies that there was a bug in the initial report that wasn't obvious but was made clearer with further information, we can easily update the report again. I personally have no problem ever admitting "I was wrong, you were right, sorry I didn't understand properly the first time". It happens. We're human and try our best to employ humans in this digital age.
 
Anyway, at the end of the day the results are what are more important. Happy customers and a solid product is the most important thing here. I'm sorry if the suggestion to contact technical support has been ever confused with being a blow-off routine. It's definitely not. It's an invitation let us help.