Hey Kevinwal, thanks for the insights. You've pretty much described how things at Cakewalk work, albeit on a much smaller scale.
 
But while you're here, maybe you can shed some light on whether a Microsoft story is apocryphal or not. I had heard that Microsoft did a user survey of what features should be included in a future version of Word, and the top 10 requests were features the program already had. That concept is not exactly unknown in these forums so it certainly sounds credible, but I was wondering if that was a true story or Microsoft mythology.

Craig, I wasn't part of that group (I was in the consulting group) but as I recall that survey did indeed happen as you say and was part of the business justification for developing the new tab-oriented command bar for the Office suite products. That change was as disruptive to users as the move to Skylight was for Cakewalk (which I suspect was done for the same reason), perhaps more so since it was applied across the entire Office suite. I can only imagine the number crunching and focus grouping that went on to make that happen.
 
 

I should point out that the reason I suspect Cakewalk operates this way is because they are still here after several decades of existence. A software company that doesn't have a robust way of gathering accurate market demand data and using it wisely will just not survive for very long.
 

dwardzala

Teksonik

Anderton
 That shows maybe sometimes it's a good idea for Cakewalk to go in the direction of what they would like to see in the program - everyone there uses it,

Sorry, got to call you on this one. Everyone out here uses Sonar as well.  To place a higher value on the opinion of those who work for CW than on the opinions of those who purchased the software is.....well I think you can take it from there.......

I think this a bit short sighted.  Those who write the software understand the full capabilities of some of the new things that they are implementing - an example is using ARA to expand Audio to MIDI capabilities.  The people who write the software are experts in its use and understand far more of what's going on under the hood and can leverage that knowledge into new feature ideas a lot better than most of us.

Sorry, I don't agree with your assumptions that knowing the inner workings of software makes make you come up with better features that make it better for users at all. Those are two different perspectives.
 
Sometimes it even shines through in markering, that devs are driving the product, not users.
Come to think of Samplitude and their "object editing". WTF is an object - seing from user musical perspective. Typical example of devs wording.
 
Even as a programmer myself, knowing object oriented programming - I ask myself what do they mean with object programming in this context of a daw. Is this a good thing at all?
 
I mean they use "object editing" as part of marketing - and it tells absolutely nothing that make you relate from a musicians perspective.
 
I don't think I ever read as much manual as trialing Samplitude. It would be Digital Performer as second, tracks is something different than we are used to, and sequences is tracks as we know them with clips and stuff.
 
And I feel about the same about Cubase - endless patchwork with strange naming, that I feel are programmers wordings more than musicians.
 
Sonar follows conventions for anybody that used analog gear and mixers before - I like that.
So searching for information in help and elsewhere - you can find what you are looking for and help yourself.
 
I spent countless of hours evaluating Cubase, trying to search reference manual and never got a hit - it was called something completely different. Developers name features inside - not users. Track templates as one are called track archives in Cubase and only available i Pro version. Looking for midi event list - it was called List Editor etc. And events in Cubase are clips as we know them. Last two slots for sends are pre fader slots - it's a mosh. Really odd ball Cubase. Cubase works well, but my God what a cumbersome interface - clearly driven by programmers not users.
 
So please - less of devs driving development and more user perspective and feature requests.
 
 
 

Teksonik

Anderton
 That shows maybe sometimes it's a good idea for Cakewalk to go in the direction of what they would like to see in the program - everyone there uses it,

Sorry, got to call you on this one. Everyone out here uses Sonar as well.  To place a higher value on the opinion of those who work for CW than on the opinions of those who purchased the software is.....well I think you can take it from there.......

It doesn't really work that way. If you really want to have a say on what goes into sonar then you need to work there. It's a company that develops a program that sells into a particular market that feeds a demand.
They are under no obligation to satisfy our individual or collective demands. We on the forum are a vocal but tiny tiny part of the Cakewalk user base. In fact Cakewalk could disregard us entirely but they don't.

In reality there are probably only a small number of people that actually drive the vision for Cakewalk's Sonar product line. I'm as sure of that as I am that when our individual feature requests get included it's because our vision and Cakewalk's harmonised at that particular point.

lfm

dwardzala

Teksonik

Anderton
 That shows maybe sometimes it's a good idea for Cakewalk to go in the direction of what they would like to see in the program - everyone there uses it,

Sorry, got to call you on this one. Everyone out here uses Sonar as well.  To place a higher value on the opinion of those who work for CW than on the opinions of those who purchased the software is.....well I think you can take it from there.......

I think this a bit short sighted.  Those who write the software understand the full capabilities of some of the new things that they are implementing - an example is using ARA to expand Audio to MIDI capabilities.  The people who write the software are experts in its use and understand far more of what's going on under the hood and can leverage that knowledge into new feature ideas a lot better than most of us.

Sorry, I don't agree with your assumptions that knowing the inner workings of software makes make you come up with better features that make it better for users at all. Those are two different perspectives.
 
Sometimes it even shines through in markering, that devs are driving the product, not users.
Come to think of Samplitude and their "object editing". WTF is an object - seing from user musical perspective. Typical example of devs wording.
 
Even as a programmer myself, knowing object oriented programming - I ask myself what do they mean with object programming in this context of a daw. Is this a good thing at all?
 
I mean they use "object editing" as part of marketing - and it tells absolutely nothing that make you relate from a musicians perspective.
 
I don't think I ever read as much manual as trialing Samplitude. It would be Digital Performer as second, tracks is something different than we are used to, and sequences is tracks as we know them with clips and stuff.
 
And I feel about the same about Cubase - endless patchwork with strange naming, that I feel are programmers wordings more than musicians.
 
Sonar follows conventions for anybody that used analog gear and mixers before - I like that.
So searching for information in help and elsewhere - you can find what you are looking for and help yourself.
 
I spent countless of hours evaluating Cubase, trying to search reference manual and never got a hit - it was called something completely different. Developers name features inside - not users. Track templates as one are called track archives in Cubase and only available i Pro version. Looking for midi event list - it was called List Editor etc. And events in Cubase are clips as we know them. Last two slots for sends are pre fader slots - it's a mosh. Really odd ball Cubase. Cubase works well, but my God what a cumbersome interface - clearly driven by programmers not users.
 
So please - less of devs driving development and more user perspective and feature request

I'm curious, what makes you conclude that developers are making all the feature priority decisions? I don't know that they are or are not, but I haven't seen anything to suggest that they are.

kevinwal

lfm
 
So please - less of devs driving development and more user perspective and feature request

I'm curious, what makes you conclude that developers are making all the feature priority decisions? I don't know that they are or are not, but I haven't seen anything to suggest that they are.

I try to build my case below.

All I know is that many really good workflow improvements are among feature requests - in my view of course, and those voted. 
 
What do developers like the most - coming up with and implementing new features!!!
And they come up with selfinvented features instead of those asked for.
It's almost like their pride is hurt not coming up with this themselves - more fun to make own features.
 
What do developers hate - clean up old ****. Too many CWBRN's ignored forever.
 
Userbase has complained forever over this, at least the ten years I looked here from time to time.
- Why implement so many new features when so many bugs remain.
 
That's basically how I see that devs are running the show - doing what they like the most and leave the rest behind.
 
Since X3 incredible improvements are made on every level - stability wise and feature wise.
And Sonar is even more incredible today - both fixes and improvements made this year.
My old habit - hysterical Ctrl+S after every operation - is starting to wear off even.
Just to clear up this not being a complete nagscreen.
 
So this is my response to someone who defended that Cakewalk do what they do, to balance things up a bit.
I can see difficulty pleasing both management and userbase - so I shut my case here.
 
But as Manuel in Fawlty Towers used to say:
- I know naaaaaaaaaaathing

 

bapu
It's not a subscription, no matter how you WANT to see it.
 
You can't make a car a squirrel just because you "see" it that way.
 

 
Did I just see a squirrel on four wheels passing me by on the high way?
 

Tell me it's no so bapu!   

I think developers DO hate to clean up old stuff. Back in my corporate days I would have to go to the IT engineers and request changes to online apps used in the plant. They hated it because of workflow. Like DAW users, every engineer had a unique workflow. So unique in fact, that it was usually faster and cheaper to scrap the app and build a new one because one programmer would look at the previous programmers coding and be stumped. They would have to try and think like the original coder to understand his workflow in order to successfully change the app.
 
I suspect Cakewalk must run into that same problem. The folks that programmed all the legacy stuff may be long gone and no one wants to dive into the old code. Something to think about. At least that's my thinking when I get frustrated with old stuff that needs updating. It keeps me calm.

We do have that problem at times - after all this is an application that has evolved for over 25 years. Which is a long time in the software industry! Fortunately we have the maturity to not follow the approach of discarding code just because of its age. Most of the newer code over the last 10 years or so is quite modern and maintainable. The older stuff can be complex but its part of our legacy that we have to maintain and plan for - we frequently refactor and improve older areas of code when necessary and time permits.
 
Regarding other speculations about how stuff is done here. Cakewalk has always incorporated both user and industry trends into our product. Feature ideas come from product managers, developers as well as others inside the company. Music software is a highly specialized industry and to innovate we need to push the envelope when necessary. If companies like ours solely relied on input from musicians and users you probably wouldn't find some of the amazing tools we have today and we probably wouldn't be in business very long. Software innovation doesn't come from end users in most industries - it takes a lot of specialized knowledge to build this stuff.
The bottom line is our software is not "crowd sourced" though we most definitely take into account trends and feature requests. As an end user you get to vote on whether our innovations are useful to you or not with your dollars...