dcumpian
Personally, I think it's a fine idea if there is a way while tracking workflow where we can stop what we are doing, click a button and tell you guys "right here, it would be great if Sonar would let me do X by doing Y...". That would be really awesome.
 
Regards,
Dan

 
Dan I like that idea a lot. In the first cut we will be doing the minimum but I don't see why we cannot expand this feature as we reap its benefits.

Anderton
With all due respect, those people who think analytics will dominate all decisions about the program, and cause less-used features to be removed, really need to review the opening post of this thread. According to Cakewalk, analytics are about expanding on the existing ways of taking the pulse of the community: 
 
"Feedback has always been important to us. We already use information from forums, surveys, press, dealers, and social media to gain perspectives on how new updates to SONAR are doing, and what needs more work. Unfortunately this doesn’t always tell us how the experience is for the larger population of customers outside of these channels. Analytics are the best way to gauge the in-app customer experience. Your feedback in all these places is very important to us, and we’d like to continue to expand our understanding of how you use our software." 
 
I think that's quite unambiguous. Also those who think analytics means less-used features will be removed need to be reminded of this:
 
We’ll be able to find out what features are popular, ways to improve features, roadblocks that users encounter, and how well new features integrate with your workflow. However, this doesn’t mean that we won’t pay attention to features that are less used. We see this as an opportunity to look at less used features and improve them. 
 
For example, those who say they don't use notation because it doesn't meet what they want (even though some people do very sophisticated work in staff view) think that means Cakewalk would assume people don't want improvements in notation. Based on the two statements above, that concern makes no sense. Furthermore if new users start to use notation and bail, that info will bolster those who want to see changes. It seems many of the concerns here are based on making assumptions that contradict Cakewalk's stated intentions. 

Speaking for myself only, my post was not as much to disagree with Cake's stated intention as to look at their track record from the vantage point of a user with a list of features that have seen minimal improvement in years- as an example, the dozen or so fixes on the list of work done to Staff View last year were small, incidental, I would almost call them "superficial". It's an easy solution for Cakewalk to demonstrate their willingness to use user input in the form of Feature Requests - implement them.
I expect that this will trigger reponses about all the great things that were rolled out last year - which I am not disputing at all. I would never have renewed my membership if that were the case. So I am going to back out of this thread. Just my opinion. Fwiw.

Brando
I'll opt out. FWIW the feature I most want improved in SPlat is notation, and it's also the feature I almost never use (in Sonar), because, frankly, well... you know (insert dead horse emoticon here). How is someone going to gauge how to improve this, and other less-than-optimally implemented features (like, say, touch), for example from "analytics"? The suggested fix for Video issues in Sonar is commonly "Get Vegas". As a result, analytics might suggest that video in Sonar is rarely used, when in fact it's implemented state has caused users to move on to use something else, either in conjunction with, or instead of, Sonar. Step Sequencer? ("Use FL Studio (Reason/Geist)") Substitute your own example of a feature you don't use much but, which, if it was better implemented, you would use a lot.
In my estimation analytics will tend to drive improvements on features that are already well implemented and used (and while I agree that this should result in an improved focus on workflow of the most commonly used features - I am afraid the result will be more "Add Track" buttons), and away from user Feature Requests.

It sure feels that the feature requests users have been submitting/posting/waiting for have been a waste of time. I am frankly disappointed in the implementation rate of user feature requests - as I see it emphasis on "analytics" is going to further escalate the slide.

Sorry but the whole thing seems like a(nother) gimmick to me.
I know - just shut up and turn it off. Will do.

Actually Brando's point is why you can't just skew the data toward "power users."  The new users won't know about the ineffectiveness of [insert your feature here] and will try to use it.  The analytics collected from them will show the workstream they are trying to use and potentially result in improvement to those features.
 
 

I think Cakewalk is being totally straightforward in describing the idea behind the move: it wants to gather data on how people use the software so that they can modify it to give people more of what they actually prefer. This is a pure marketing move - it's not about finding and fixing bugs, not about finding what features users want. It's all about what users do with the program.

Very dangerous trend here - not because of the privacy angle: Cakewalk will not do anything sinister. Paranoia has no place in this conversation. It's dangerous because it has the potential of sending Cakewalk in the direction of adding generic features in order to satisfy the lowest common denominator: Garage Band or Magix Music Maker will be the result.

But then again: what if most Sonar users want a simpler DAW? what is Cakewalk supposed to do, alienate the majority of their clients?

I guess the solution for every user is to decide if the current trend is something you want to support with your wallet. I know what my answer is - but that's only good for me. Others need to find their own answers...

dwardzala
Actually Brando's point is why you can't just skew the data toward "power users."  The new users won't know about the ineffectiveness of [insert your feature here] and will try to use it.  The analytics collected from them will show the workstream they are trying to use and potentially result in improvement to those features.

It does seem that Cakewalk is doing this for the clueless new users in the interests of making Sonar easier/simpler to learn and operate.  That's ok in itself, but doesn't do much for experienced users.  For these, problem reports and feature requests are probably more significant.

Brando
Speaking for myself only, my post was not as much to disagree with Cake's stated intention as to look at their track record from the vantage point of a user with a list of features that have seen minimal improvement in years- as an example, the dozen or so fixes on the list of work done to Staff View last year were small, incidental, I would almost call them "superficial". It's an easy solution for Cakewalk to demonstrate their willingness to use user input in the form of Feature Requests - implement them.
I expect that this will trigger reponses about all the great things that were rolled out last year - which I am not disputing at all. I would never have renewed my membership if that were the case. So I am going to back out of this thread. Just my opinion. Fwiw.

I think you're probably a typical user - happy about what's been improved, disappointed with what hasn't if it's a feature that matters to you. For example I still keep hoping for a "drum machine mode" for the PRV, but then again if Cakewalk came to me and said "We have time to do patch points or drum machine mode, you can have one" I would have picked patch points.
 
Realistically there will always be a desire on Cakewalk's part to do more features and fixes than the current level of resources allows. Therefore everything will need to be prioritized, and it's a balancing act. There are two main ways analytics can help.
 

• SONAR is always picking up new users. If enough people choose to connect with their account, Cakewalk can see what frustrates those who are being exposed to the program for the first time. Those here who think "Well I don't use feature X because I don't like it so Cakewalk won't do anything" aren't considering the value of data from new users.
• There are some bugs that are deep in the program or intermittent, and it can take a lot of time to reproduce the bug in order to find out what's causing it. If analytics automatically provides a really clear set of steps to reproduce, this could cut down drastically on the time required to fix bugs, therefore freeing up resources to either improve features or fix more bugs.

 
Cakewalk will always prioritized based on what they think will provide the greatest positive impact to the greatest number of users. Analytics provide yet another set of data points to help with those kinds of decisions.

Noel, your link is broken.  Edge can't find the site.

Paul P
 
It does seem that Cakewalk is doing this for the clueless new users in the interests of making Sonar easier/simpler to learn and operate.  That's ok in itself, but doesn't do much for experienced users.  For these, problem reports and feature requests are probably more significant.

Cakewalk has made it clear that using analytics doesn't obviate their other methods of canvassing users. But perhaps more importantly, power users are the ones who push the system harder, and find bugs that new users would never find because they're just doing the basics. I think analytics would make it much easier to fix the kinds of bugs that vex power users, especially because the power users may not have the time to really investigate a bug in order to submit steps to reproduce...but if analytics does that for you, then that would be tremendously helpful for troubleshooting.
 
Also, because of the rolling updates, with some features everyone is a "new user" because they've never been exposed to that feature before. Being able to collect data on whether Cakewalk made the right decision or not regarding a new feature will be valuable feedback regarding future plans. For example enough people seemed to like upsampling that Cakewalk improved the feature with real-time upsampling on playback. In the future those kinds of decisions can be based on hard facts regarding if and how people used a particular feature.
 

Beepster
 As for the smartphone comparison... I don't use those and never will. If I was ever in a situation where I HAD to use one I would do everything in my power to circumvent every creepy little thingamadoodle installed on it designed to collect data.

My kind of guy!
 
How would this work if you keep your DAW offline?

BrandoIn my estimation analytics will tend to drive improvements on features that are already well implemented and used (and while I agree that this should result in an improved focus on workflow of the most commonly used features - I am afraid the result will be more "Add Track" buttons), and away from user Feature Requests.

It sure feels that the feature requests users have been submitting/posting/waiting for have been a waste of time. I am frankly disappointed in the implementation rate of user feature requests - as I see it emphasis on "analytics" is going to further escalate the slide.

Sorry but the whole thing seems like a(nother) gimmick to me.

In all fairness, Cakewalk is at a crossroads: power users are a minority of their clientele (you can tell from the postings on this forum) and the super-saturated DAW market makes it almost impossible to pry users from the competition. The most promising market is casual users and total beginners.

What is Cakewalk supposed to do? Cater to the minority? Lose potential customers?

That's the real issue behind all the marketing-driven moves of late (plus the ones coming up): LANDR, analytics, etc. It's a business, not a science project (even though there is great danger for Cakewalk itself: casual users and total beginners are less likely to pay for using the program - you know what I mean...)

All we can do as users is decide if the trend is one we benefit from and then act accordingly.