• SONAR
  • No, I won't contact tech support. (well, yes, I did) (p.3)
2013/10/23 13:37:07
Lynn
Studious
Yevster,
 
I understand your frustration.  Filling out a bug report is a major workflow-killer!  "Contact tech support" feels like time wasted (you just DID contact tech support).  You then have to make new contact and re-describe everything.
 
But...I think you're being overly-stubborn.  You took the time to post this thread and reply to it several times already.  With a fraction of this energy you could've already contacted tech support.  Did they specifically say "call"?  I assume you could just email them.
 
In the meantime, you could use the forum to try to resolve or verify your issue.  Best of luck!


I 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.  He said not to leave my program idle for any length of time.  I told him that due to unforeseen circumstances, it wasn't always possible nor desirable to do so.  This has never happened before, and after removing TE from my project, I haven't had a problem since.  This could have been explained in the e-mail they sent me, but instead, they chose to send me on a wild goose chase with nothing being resolved.
 
Since this is such a minor problem, it's not worth losing sleep or time over, but it could have been handled better.
2013/10/23 13:43:00
Seth Kellogg [Cakewalk]
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. 
2013/10/23 14:21:23
SuperG
Thus endeth the lesson.
 
Never be so sure of yourself to permit yourself a bit of instransigence.
2013/10/23 14:35:34
Fog
SuperG
Thus endeth the lesson.
 Never be so sure of yourself to permit yourself a bit of intransigence.

 
never knew of that word till today.. notice ya misspelled it.. where is my prize for noticing ? :)
 
 
 
 
2013/10/23 14:46:00
jb101
That is quite embarrassing..
 
The whole 'controller envelope "in this case, I'm pretty sure it is" a bug' thing, not the misspelling of intransigence..
2013/10/23 14:47:53
stevec
I'm curious... when something moves from a bug report to technical support, does it move to a different team within CW?
 
2013/10/23 14:48:51
jb101
And talking of spelling, was it really a "rouge" controller envelope?  I know X3 is working better with colours, but "rouge" seems very cosmopolitan.  
2013/10/23 14:54:35
stevec
Well, just going from memory I think Controller events follow the PRV, so if the PRV notes were red I suppose it technically is possible. 
2013/10/23 14:57:47
Splat
Yes I'm more into trying to solve issues online as this allows space. I appreciate others may appreciate the exact oppersite. Support departments on the whole should be writing up knowledge base articles... For people who don't want to spend money on international calls an online chat option would be invaluable.

In a nutshell we should be free to choose which medium we wish to communicate in.... And that includes the forums. Of course when things get muddled nothing replaces a phone call.... But for me this is a last resort.
2013/10/23 15:16:55
Ryan Munnis [Cakewalk]
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.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account