X2a = nothing but solid

Thanks for the follow up brconflict. I truly do appreciate it.
 
Regarding helping out, I don't personally manage anything regarding the beta team but we do of course recruit beta testers from time to time. If this is something you're personally and genuinely interested in, we do have an application form here: http://www.cakewalk.com/beta/forms/ (now that I look at this form, we need to update it.. it's kinda ugly... I'll try to get that updated soon). Anyhow, that's a good way to get involved but obviously requires an NDA. You might not hear back unless we're recruiting though.
 
To elaborate on the systems in place for collecting feedback about the products stability, bugs, features, etc. there are quite a few systems in place. Some automated, some not. These are a few of them:
 
The Fault Reporter system:
 
The focus on this is stability. It's a bit different from the Problem Report/CWBRN form.
 
Built by a few members of our support team with help from our developers. Willy wrote a bit about this a while back. Willy's post: http://blog.cakewalk.com/what-happens-when-you-send-a-problem-report-to-cakewalk/ .  
 
Essentially the way this process works is if SONAR crashes, a .dmp file is sent to our servers. We have a home-brewed tool we created that analyzes the crash and logs cases directly with our developers by communicating with our internal bug tracking system. It provides us with a ton of data, both in terms of what our biggest crash offenders are, as well as a lot of information we can extract at the time of the crash should we need to investigate a certain section of code or third-party component.
 
For example, as of this exact moment the most reported crash issue coming in is something that we resolved with the X2a update. When I run the same report against X2a, there are no duplicates, indicating the issue was resolved. What does that tell us? That a LOT of people haven't even installed the update still to this day. I worked with a pretty big VIP artist today who was experiencing crashes and was under the impression he had X2a installed. He's a very smart and talented guy. Turns out he didn't have it installed. It's easy to make mistakes. He's probably been under the impression that "X2a isn't that stable" meanwhile the whole time he was on the release version which did have legitimate stability concerns that we patched right out of the gate.
 
Anyhow, this entire system is pretty automated, but it doesn't get ignored as a result of that. Making sense of the information does require real-time interaction as well... something I work with personally very often and our developers work on.
 
The Problem Reporter/CWBRN form: http://www.cakewalk.com/support/contact/problemreport.aspx
 
The focus on this is if features are working as designed. It's a bit different from the fault reporter.
 
You already know about this, but to give you the back story about why it is even here. We have our internal bug tracking system, but customers want a way of providing us with details sometimes. This form allows customers a means of logging a report and getting some type of official acknowledgement from Cakewalk of whether or not we're aware of the issue. A lot of the cases that come in are easily resolvable. In fact, the VAST majority are (over 80%). What this means is that often times people think they are experience bugs but we know we have a solution for the issue. That just goes to show there can be a confusing perception about things depending on your experience level and whether or not you've ever interacted with tech support before. Most commonly reported "bug" is audio dropouts, but 66.5% of people have not provided what audio device they're even using. 
 
Often times when bugs do come in that are legit, we track down an internal report that might have come in from our QA team, our TS guys answering phones and emails, or our beta testers. Sometimes people log the same report multiple times, so data can get a bit skewed. If you ever see us return something as a "duplicate", this is why. We're trying to keep the numbers accurate and when we resolve a case, notify people properly.
 
Anyhow, the entire point of the form is really to notify people when we have fixes for issues. You provide us with your email address and the specific issue, we sync it up with our internal system, when our developers return a fix and the fix is released, we update the reports to notify you. It's nice to receive a report that an issue has been resolved with an update that's now available. This is, however, why there can seem to be huge periods of inactivity with the form, because we only update things when our internal reports are being migrated around and fixes become available to the public. 
 
Tech Support & Customer Service: http://www.cakewalk.com/Support/contact/default.aspx
 
Everyone working in TS and CS is in one way or another an extension of our Quality Assurance team (and theirs of ours). We have access to logging issues in the same manner so we'll forward things along and get them escalated by our QA leads who specialize in these issues. We're all pretty close here at Cakewalk, so it's very easy for me to hop down to someone and say "I just spoke with this guy on the phone about an issue he's experiencing, what do you think?". Noel could tell you I do this quite often.
 
On the topic of support, I can understand that sometimes things don't go well. Nobody (myself included) is perfect and we do get stumped sometimes. The important thing to identify is that none of us are working from scripts... only from our brains and the experiences we've had. Every single TS and CS person we have on staff is actually extremely qualified (degrees in audio production, engineers at local recording studios, live sound technicians, legitimate performing musicians, use all of our competitors products as well, etc.). I can't think of a single person on our support team that isn't insanely involved in many aspects of music creation, production and performance.
 
I think the important thing for getting off on the right foot with anyone in support is acknowledging the challenge of the job. Even with all of the experience in the world, it's not easy if not being given a chance from the get go. It's on us to handle these situations professionally though, so if we're not, tell me about. Send me a PM. I'll follow up.
 
The Feature Request Form: http://www.cakewalk.com/support/contact/featurerequest.aspx
 
Pretty self explanatory, but definitely fill this out. Our Product Managers review it. It's a great place to express what you'd like to see.

 
The Beta Team: 
 
Yes, we do have a beta team and they do test our products. This is important because SONAR isn't locked down to a single OS or hardware configuration. The beta team gives us tons of solid feedback outside of the testing we do internally.
 
The Forum: 
 
I'm not going to leave this out. 
 
Your opinions are important. We obviously do pop up and read the forums from time to time. We try to interact when we can, but even if we're silent occasionally we're not ignoring things. It is important for us to understand if people are actually happy with the features. Correct workflow, incorrect workflow, bugs aside... if a feature is working "as intended" but people are using it differently then we thought they might, then this type of feedback is important for us and we do pay attention. It's helpful for how we approach what's next.
 
What isn't helpful, is requesting us to "fix things" with absolutely zero context. The last three recent threads I personally read on the topic of X2a/X2b were all started by members who have no history of internal cases with us and did not provide any indication of what is working or isn't working for them. It seems like border-line trolling. This isn't to say some people aren't expressing legitimate concerns, please don't mistake what I'm saying... but those people with constructive criticism are providing context right from the get go. I've seen a number of helpful users ask for clarification on some of these threads and to try helping, which is great (thank you!). Unfortunately their good intentions appear to be being drowned out in some cases.
 
...
 
These are just the systems I'm interacting with directly. I'm sure our marketing team could tell you a whole different set of data they get from surveys, social media, sales ($$$), etc.
 
I guess all I'm trying to express is that I'd much rather (personally) see people taking advantage of the systems above and interacting with us versus against us. The meetings I'll be in all week (including the two hour one I just came from) are ALL about things everyone is expressing they'd like to see as improvements made to SONAR. We collected that information from everything above.
 
All of these systems are helpful to us. I hope in return it can be helpful to you and other folks. It's important to communicate this I believe. Hopefully future announcements from Cakewalk will speak for themselves so I don't have to.

Fantastic post Ryan!

I believe I did subscribe to the Beta program, but never heard anything back. Not a huge deal, but I'd like to be invited.
 
Anyway, these are the methods I'm aware of, minus I left out the Crash Reporter, because we don't really get feedback from that. You never know if the software crash reporter is really sending useful info, or if the server(s) are no longer logging that information (proverbial buffer overload).
 
Personally, I feel I have made efforts to (at least 90% of the time) to explain what I did to see an issue, or at least explain what I was basically doing. It's tough to report some issues without a good logging facility to use as a debug. Sometimes the steps can be forgotten, or slightly mis-interpreted. If I could recreate all the ghosts I found in video format along with some logging, we could really squash those. But the logging capabilities of X2 I found aren't really there for me to enable. I have screen-capture software for a Mac, but obviously, I don't use Sonar on the Mac. 
 
It may sound a bit overbearing, but for these types of things, I'm surprised Cakewalk doesn't provide a good logging facility in X2 that users can run locally to sort of watch actions, even if this slows down the machine. For multi-proc machines, this would be more possible I think.
 
For the Bug Report tool, I found it may take a couple of months before the bug is submitted to the Dev team(s). At least, that's when I might receive a status update. Like you mentioned, if you're on the phone with someone and need to run a question to the Dev team(s) like you mentioned, hopefully you'll regard the forum users the same way. But the reality is, calls do take precedence. I can't fault there, but again, i don't have the time-window I'd need to call in.
 
It's good to hear, and thanks for reporting, that many of the things here and on support calls and such are being discussed this week. That's a positive step. I just wish all of the DAW makers in the field could afford to be a bit more transparent with open issues and communications. For me, just knowing a specific type of issue is "known" whether or not it's going to be addressed, is a key essential that I look for. It's transparency at a minimum cost to strategy. It goes a long way, though.
 
Thanks for the response, Ryan.
 
 
 

Transcending Music
X2a = nothing but solid

solid is relative

Seth, that would be my assumption, based on how the business I work for runs. At the very least, I see that an issue or bug report I submitted is indeed being viewed, and that's certainly something positive. Thanks!

Ryan Munnis [Cakewalk]

brconflict
 
Unfortunately, Cakewalk still prefers the old-school method of waiting for us all to call in (typically when the ghosts in the machine run and hide) or report only bugs that are easily duplicated. Most of the issues people have aren't easily duplicated, so support tends to never see a majority of them. How they can fix those issues is by working with people in the forum. Plus, people like me have day-jobs and don't use Sonar except at night. Support or On-Call support isn't available from CW.

To be correct here, us providing a system for users to log bugs and get confirmation of the status a bug is at doesn't mean we don't do anything until that happens. Do you think we don't have other systems in place for logging issues? It sounds like you're implying people at Cakewalk just sit around all day until people complain about something, which is so far from the truth. I don't understand how you can make a statement like this unless you work here and know our day to day operations, which if you did you'd know how incorrect this is.
 
We work directly with a huge amount of people that never visit the forum ever. Official support methods are in place for people to reach out to us if they need help. We identify a lot of issues, and correct a lot of issues. The ones we can't correct, we follow up with our QA and Development teams. Sometimes we don't have an immediate answer, sometimes we do. We make progress all the time. It is factual that a huge chunk of the time when people fly off the handle about the stability of X2a, we check our records, and find out they've never reached out to us ever... which is incredibly frustrating for us. A lot of the times when we do get to the bottom of it, we find out it's not a problem with SONAR at all. Every time I mention this people think I'm making it up. They reply with "why would someone do that". I can't tell you why, but they just do. It's weird to me.
 
Anyhow, if you're wondering where my defensive reply is coming from, it is because we need to continually work together and not against each other. Every time I read something about how Cakewalk is not available for support, it hurts both customers and the final outcome of the product.

I think what a lot of people don't understand is how this forum is only a very small partition of the users who use cakewalk products.
ive been using cakewalk products for over 10 years now, but I only joined the forum 3 years ago.
there's also those that barely use the internet except to check emails.
 
there are so many things we just don't even know that goes on at cakewalk so im not about to pretend I do.
 

brconflict
How they can fix those issues is by working with people in the forum

 
not a bad idea actually, im only guessing but im just not sure there's as many on cakes staff as we think, so each one of them is stretching themselves hard.

X2 is a great program. Just needs a patch.
 
Vista? I never liked Vista.
 
That is all.

All signs point to X3. I'm pretty happy with X2 as is so...I'll just wait and see what Cakewalk has to offer. If it's worth the upgrade, then I'll upgrade. If not I'll happily continue on with X2. I've never considered leaving Cakewalk.

@ Beepster: Vista Vista Vista....
 
Thanks Ryan and Seth!!!

stevec
+1    Ryan's post deserves visibilty beyond this thread.  

+1000

cparmerlee

stevec
+1    Ryan's post deserves visibility beyond this thread. 
 

With no disrespect intended toward anybody here (Cakewalk or users), it seems to me that all Ryan said was that there are systems for reporting problems.  That really isn't news, is it?  It is a helpful reminder, but it doesn't really address the main concerns that have been expressed here.
 

That was kind of the point...   I'd wager that many are not aware of the variosu systems as Ryan described them, which IMHO is good info.   And once the next SONAR version is known this thread will be lost in the ether, and Ryan's post along with it.
 

lawp
it's like asking for the recipe and being told about cooking utensils

You've missed my point completely. I'm telling you that many people are asking for the wrong recipe. Sarcastic posts like this do not help, especially when I took a lot of time out of my day to genuinely address some concerns and provide some insight into how inaccurate a lot of these topics about the stability of X2a is. I'd challenge if you even read the post.
 
Thank you to everyone else for the positive words. I read all of your replies and they meant a lot to me.
 
Let's move on from this topic for now and refocus on helping one another.