irvin

stevec

irvin

John T
It's just like Orwell predicted. One day, UI enhancements, the next, fascism. Follows like night follows day.

True, for as long as there are loyal soldiers like you, willing to kill and be killed for a cause they trust, but can never understand.

And you do?
 

I don't have to worry about those things. I'm a born general and fight my own causes. Soldiers are more like attack dogs, ready to defend their masters even at the cost of their own lives. It's a different mentality - soldiers enjoy beta testing and feel the need to show their loyalty, generals map strategy; soldiers die alone in a distant desert, generals plan astute attacks in air-conditioned rooms and usually die of old age, surrounded by their medals. Soldiers trust their generals, generals sell their vision to their soldiers. Nothing evil about it. Just different roles for different people.

Wow, we do think fairly highly of ourselves...
 
I'm trying to image what type of "strategy" one could possibly believe they're mapping, right here and now.   Or what type of "role" one has other than a simple participant.  There are no distant deserts, medals or the like.  This is a thread about an upcoming feature in a DAW.   One that can be disabled.
 
I wonder what will this discussion will mean six months from now, after a hundred other topics, discussions, opinions and speculations have been made.   Hey, anyone remember the doom and gloom when Cakewalk first moved from Roland to Gibson?  Yeah, the last two years have apparently been terrible for Cakewalk.   And the membership program?   Bad...   Abysmal even.   
 
 
 
 
 
PS...  in case it was unclear, this is more glass half full than it is soldier, just based on the way things have actually turned out so far. 
 

This really is too good. To have suggested people here frequently overstate their case, and have the counter-argument be that I'm like a soldier under the control of powerful and incomprehensible dark forces. I'll grant I was taking the mickey; don't really need to when some people are practically giving it away.

FanCake
So I turn this feature on, let's face it all cakewalk are probably interested in is what underwear I am wearing and whether I am into bovine sexual activities.

 

bapu
The only thing about analytics I'm paranoid about is that Cakewalk discovers I work in the nude.

It's a data match already.

bapu
The only thing about analytics I'm paranoid about is that Cakewalk discovers I work in the nude.

In the midst of all the tension, yet again Bapu makes me laugh out loud. You are hilarious dude:)

ChristopherM

Anderton
Chrome thinks I want dog sweaters, leashes, and chewy treats.
 

 
You'll be surprised at how good you look in a stylish dog sweater (although the leashes are for special tastes only). The treats aren't called treats for nothing, either.

Wonderful....    thanks for that mental image. 
 

 

brconflict
 
And, don't forget! If you don't want to participate, you don't have to. Turn it off. It's that easy!
 
I'll give credit to CW for at least announcing this, vs. tossing it in without you knowing or being able to opt out. NOt everyone is this transparent.

Yes, they do deserve credit for this.  Advance announcement and optional levels are very positive moves.

 

BobF
I am disappointed that effort is being expended to integrate and deploy a tool that is supposed to help Cakewalk figure out what needs to be done - where to focus work.

I'd argue you're misinterpreting the effort here, or at least missing the mark on how this could be helpful (whereas other current avenues of communication are not). As an example:
 
Noel mentioned "dropouts", so I'm sort of just reacting to that considering conversations I've been in repeatedly behind closed doors here. For years our developers have asked questions to those that have close interactions with end-users things like:
 
"What are the most common causes of crashes that users experience?"
 
Previously we only knew if people reported them directly. We worked towards resolution to this by creating the fault reporter when SONAR crashes. Collecting, parsing, analyzing, and reporting crashes via this system is all automated. This has resulted in countless stability fixes. Of course crash reporting can all be done manually as well, but the amount of fixes that required zero human action (other then a developer fixing the crash) has proven to have been well worth the effort.
 
"What would you say are the most common questions customers call about for assistance?"
 
We have a giant database of phone call & email history in our internal ticketing system that allow our support team to easily reference what the big ticket items are. The forum itself is also offers a ton of insight into user hangups. It's pretty easy to come to a conclusion on what users often need help with.
 
"What are the most common bugs users run into?"
 
We created a Problem Reporter so that users and Cakewalk staff alike could log, report internally, and provide notification of bug resolutions directly to end users. This has resulted in countless fixes over the years. We're always working towards improvements to this, but even today it directly integrates with our internal bug tracking software and fault reporting system.
 
"What are the most requested features made by users"
 
We currently have this Feature Request forum and are building a new Feedback Portal to improve upon this experience overall. In the past it was just a suggestion inbox. We're working on making this much better.
 
etc. etc.
 
 
My point is mentioning this is that we're always trying to deliver information from end-users to development in a more efficient manner. Those are only a few brief examples. But here's the thing, Cakewalk developers often also ask things like:
 
"How often do customers experience dropouts?"
 
Honestly, I'd love to know.
 
The answer to this question is always extremely subjective. Support representatives may say "quite often" because they're often on phone calls with customers using integrated sound cards with poor performing drivers before they've learned how to configure SONAR for use with their new audio hardware. QA might say, "occasionally" because they're used to testing and working with beta-testers who own and work with superior hardware but also know beta-builds can be unpredictable from time to time. Developers themselves might say "never" because optimizing their system for audio performance is completely second nature. End users themselves will give a different answer every time based on their own subjective experience.
 
The term "dropout" itself is also interpreted a few different ways. Often times customers report simply, "I get tons of dropouts", but what exactly are they referring to? Are they referring to clicking and popping during playback, or are they referring to the audio engine stopping? We've even had users refer to timeline intentionally stopping at the project end as a "dropout" (yes, this is true). So if a email/call/bug report comes through like that, what do we do with that data? Is it factual to refer to that as a "dropout", or do we make a clear distinction? How do we build an accurate report of whether or not dropouts are a plaguing customers? How do we build an accurate report of whether or not a particular build of SONAR we just released has increased or decreased the number of dropouts end-users are experiencing?
 
The problem is that nobody can really give the developers a helpful answer here. It's usually vague, very subjective, and lacking any specifics helpful to troubleshooting and making improvements.
 
Noel mentions an example of doing cool & helpful things to assist someone who many be experiencing recurring dropouts. This is part of the spirit of analytics. Seems like a lot of people are fearful that this is being implemented while feature requests right here on this forum are out in plain sight, but I'd argue that none of the previous systems we have in place can provide an answer to something like "how often do people experience audio dropouts". Very different goal if you ask me.
 
I'd also argue that as of today, it's very hard for us to communicate whether or not SONAR Newburyport experiences fewer dropouts then SONAR Braintree. I could dig up a report in regards to crash stability (because of our aforementioned fault reporter), but digging up a report in regards to audio engine performance would require benchmarking. In other words - much smaller set of data; difficult to get real metrics outside of control group; takes up lots very valuable time.
 
So I guess my ultimate argument is that effort in this will provide us with insight not currently (nor easily) available to us. It doesn't replace other areas we look to for insight.

Ryan Munnis [Cakewalk]
"How often do customers experience dropouts?"
 
Honestly, I'd love to know.
 
The answer to this question is always extremely subjective. Support representatives may say "quite often" because they're often on phone calls with customers using integrated sound cards with poor performing drivers before they've learned how to configure SONAR for use with their new audio hardware. QA might say, "occasionally" because they're used to testing and working with beta-testers who own and work with superior hardware but also know beta-builds can be unpredictable from time to time. Developers themselves might say "never" because optimizing their system for audio performance is completely second nature. End users themselves will give a different answer every time based on their own subjective experience.
 
The term "dropout" itself is also interpreted a few different ways. Often times customers report simply, "I get tons of dropouts", but what exactly are they referring to? Are they referring to clicking and popping during playback, or are they referring to the audio engine stopping? We've even had users refer to timeline intentionally stopping at the project end as a "dropout" (yes, this is true). So if a email/call/bug report comes through like that, what do we do with that data? Is it factual to refer to that as a "dropout", or do we make a clear distinction? How do we build an accurate report of whether or not dropouts are a plaguing customers? How do we build an accurate report of whether or not a particular build of SONAR we just released has increased or decreased the number of dropouts end-users are experiencing?
 
The problem is that nobody can really give the developers a helpful answer here. It's usually vague, very subjective, and lacking any specifics helpful to troubleshooting and making improvements.

 
Thanks. I think this is the clearest explanation yet on why Cakewalk wants to do this.
 

brconflict
I'll give credit to CW for at least announcing this, vs. tossing it in without you knowing or being able to opt out. NOt everyone is this transparent.

I agree that it was a good idea for Cakewalk to announce this before implementation and thereby save us from a major surprise on release day, like happened last time around.  This way we are forewarned, can make deliberate decisions and have gotten our opinions out of the way.  Release day should be a quiet affair.

Anderton

Ryan Munnis [Cakewalk]
"How often do customers experience dropouts?"
 
Honestly, I'd love to know.
 
The answer to this question is always extremely subjective. Support representatives may say "quite often" because they're often on phone calls with customers using integrated sound cards with poor performing drivers before they've learned how to configure SONAR for use with their new audio hardware. QA might say, "occasionally" because they're used to testing and working with beta-testers who own and work with superior hardware but also know beta-builds can be unpredictable from time to time. Developers themselves might say "never" because optimizing their system for audio performance is completely second nature. End users themselves will give a different answer every time based on their own subjective experience.
 
The term "dropout" itself is also interpreted a few different ways. Often times customers report simply, "I get tons of dropouts", but what exactly are they referring to? Are they referring to clicking and popping during playback, or are they referring to the audio engine stopping? We've even had users refer to timeline intentionally stopping at the project end as a "dropout" (yes, this is true). So if a email/call/bug report comes through like that, what do we do with that data? Is it factual to refer to that as a "dropout", or do we make a clear distinction? How do we build an accurate report of whether or not dropouts are a plaguing customers? How do we build an accurate report of whether or not a particular build of SONAR we just released has increased or decreased the number of dropouts end-users are experiencing?
 
The problem is that nobody can really give the developers a helpful answer here. It's usually vague, very subjective, and lacking any specifics helpful to troubleshooting and making improvements.

 
Thanks. I think this is the clearest explanation yet on why Cakewalk wants to do this.
 

+1- enough for me to soften my earlier position. Makes sense, and there are likely other similar scenarios where this approach makes a lot of sense. Especially for benchmarking new releases performance versus prior releases. I still would want to test it to prove to myself there is really no overhead or glitches. IMO though, using analytics to mine for potential workflow improvements is still a mistake - for the reasons already outlined. Just my 2 cents.

Am I wrong to think that the feedback portal and the analytics will be tied together? Sounds like a good place to opt in or out.