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.......

And I have to call you on taking what I said out of context . The sentence before what you quoted said:
 
"To say that Cakewalk goes in the completely opposite direction of what people want is simply not true, nor is it a bad thing that Cakewalk has developed features that may not have been 'clamored for' but have been extremely popular."
 
I already showed that Cakewalk has been very responsive to the community. It's absurd not to place value on the contributions Cakewalk's developers can make on their own - they develop for it, they know the code, they know what's possible, and come up with ideas that only people "on the inside" would likely come up with...like VocalSync, which leans heavily on ARA integration to make it possible.
 

Nor do the users.... Aye, there's the rub.

Thanks Scook! That one simple link has answered so many of my questions. Thanks so very much! An informed community is a polite community!
And I've been on this rock for a few years, not the most tech savvy but you don't get this much gray hair from lack of understanding either. The membership program, with such a perfect analogy given by Craig earlier, does appear to be a win-win concept. As long as venues like this remain, and I laugh at times as such eager support is given here for sonar products that I though were long obsolete. Try and get Microsoft to help ya out with a bug in Win98....sorry, made myself chuckle a bit. Kinda makes me look twice at my old Sonar6 producer CD that I never learned (had time) to use, that I tossed with an old outdated machine.
Those that are afraid of the koolaid, all I can tell ya is "Cheers!" as I toss mine down! Tasty!!

Teksonik

charlygNor do the users.... Aye, there's the rub.

But the users pay the bills..........especially with a "membership" paradigm.
 
Ok I'm done.  You can't reason with people who are in "Defense of DAW mode". You see it on every DAW forum.

Sadly, I agree, Teksonik.  Seems like if you are anywhere reasonably critical of the software or company actions, it does seem like people jump all over you, and "you're so wrong, how dare you be so critical, and you should feel lucky that you even get a chance to pay for and USE the software".  I've been around with Cakewalk since the Pro Audio 9 days, and I'll probably be with it for many years more.   So, I don't plan on leaving the software any time soon.  
 
However, as I mentioned before, I haven't upgraded from X3 yet, and I have presented concerns on why I haven't been willing to do that.  Eventually, maybe I will, but right now, I am concerned about how things are progressing, notwithstanding what forum members might try to get me to believe.  I guess time will tell.
 

Teksonik

charlygNor do the users.... Aye, there's the rub.

But the users pay the bills..........especially with a "membership" paradigm.
 
Ok I'm done.  You can't reason with people who are in "Defense of DAW mode". You see it on every DAW forum.

Users pay the bills for the program that comes closest to doing what they want to do. I don't think they care where a great feature came from as long as it's a great feature. 
 
And this has nothing to do with defending a DAW. This has to do with correcting misinformation and discussing the process behind how, why, and in what way programs advance.
 
This all started because someone was clueless about the membership program and that was clarified. Then you claimed that Cakewalk wasn't responding to what people wanted and going in the opposite direction, and that was wrong (as shown by the list of what was done specifically in response to user requests) so it needed clarification too. Then you selectively took half of a paragraph to justify an argument against something that expressed the same opinion you did. That's okay, misunderstandings happen, but I really don't see the big difference between you saying community input is important and me saying that community input is important. I just happen to consider the developers to be part of the community and their input is important, as has been proven by their introducing features no one "clamored for" yet have been extremely well-received. 

charlyg
 
You can't roller skate in a buffalo herd.

You can, but not for long.
 
 
 
Don't ask me how I know, I just do.  Okay?     

Teksonik

dwardzala
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.

The guys who write the code know the code but that doesn't mean they know how everybody else uses that software or that their ideas are better than those who spend all their time using the software not writing the code. Sometimes the people who write the code can't see the forest for the trees.  That's why user input is so important to the development of any software. The developers can't have all the ideas nor do they necessarily always have the best ideas.

Yes, and in my opinion there is an appropriate balance of user input and developer input into the choice of which features to implement in what priority.  Your post implied to me that you dismissed any input from the developers and that all user input was ignored (which I don't agree with), which is why I stated your position was short sighted.
 
It should also be noted that most (all?) of the coders at Cakewalk are musicians (and recording musicians at that.)  That's not necessarily the case with other software development (say graphics software, or business software.)  This is a somewhat unique situation.

I don't know how it works at Cakewalk but I do know how it works at the companies I worked for as a software developer. It is generally not the developers who make feature decisions, it is subject matter experts in the discipline toward which the product is marketed that collate the requirements and develop feature priorities. At Microsoft we called them Program Managers, and while it varied from team to team, they typically developed the feature specifications very completely for their area before the developers began coding, right down to the user interface design, including artwork by graphics designers.
 
PM's spent a lot of time traveling and talking to customers and analyzing competitive offerings as part of the process of feature development and prioritization. The more technical PM's often built feature prototypes (often with customer groups) for validation of ideas and proposed workflows.
 
At another company we built software for civil architects and engineers and our PM's were without exception credentialed civil engineers or architects (not the software kind.) I would expect that Cakewalk has a similar approach and no doubt has a cadre of musicians, engineers and producers making these kinds of judgments.
 
The bottom line is that if a feature appears in the product, you can bet that a critical mass of demand has been fully demonstrated to company leadership complete with ROI established before a nickel of development resources were allocated.
 
It's kind of axiomatic in the business that the most vocal customers almost always advocate for what research ultimately shows to be the least needed set of features. While everyone makes mistakes, I personally trust that Cake's feature decisions are in the best interest of the most users.
 
Cheers, all!

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.
 
 

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.
 
 
 

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.

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!   

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...