jatoth
Charlyg, You obviously don't do a lot of MIDI editing. Some of us do. Why chime in and post that you don't need or want that fix? A bit narcissistic, no?
Fixes help everyone, including Cakewalk. The more stable Sonar gets, EVERYONE wins.
 
I vote for at least a few months of just fixes and stability issues. NO new features.

And I don't agree. Not any more narcissistic than wanting YOUR fix. There are more to bug fixes than a couple of lines of code. It may be integral to the whole program, and have to be rewritten from scratch. How is it that you know it's fixable?
 
Asking for a program to not improve itself(features count) in one area so that it can fix another is a pipe dream. Unless your involved in the programming, you are as clueless as I. And the program will also be obsolete in a few years as the competition passes it by with new features that SONAR decided the users didn't want(bug fixes only).
 
I am also pretty sure it's not the same people writing new code as writing fixes...... Which means the skill set may be different.

The only thing we know for sure is that there are separate coding teams for bug fixes and feature development so there's no resource compromise here yes?

Bristol_Jonesey
The only thing we know for sure is that there are separate coding teams for bug fixes and feature development

This encourages what is called "Throw-it-over-the-wall" development and may explain what we are seeing.

I would think it points to having enough people working to be able to do it all fix and create. 

charlyg

jatoth
Charlyg, You obviously don't do a lot of MIDI editing. Some of us do. Why chime in and post that you don't need or want that fix? A bit narcissistic, no?
Fixes help everyone, including Cakewalk. The more stable Sonar gets, EVERYONE wins.
 I vote for at least a few months of just fixes and stability issues. NO new features.

And I don't agree. Not any more narcissistic than wanting YOUR fix. There are more to bug fixes than a couple of lines of code. It may be integral to the whole program, and have to be rewritten from scratch. How is it that you know it's fixable?
 
Asking for a program to not improve itself(features count) in one area so that it can fix another is a pipe dream. Unless your involved in the programming, you are as clueless as I. And the program will also be obsolete in a few years as the competition passes it by with new features that SONAR decided the users didn't want(bug fixes only).
 
I am also pretty sure it's not the same people writing new code as writing fixes...... Which means the skill set may be different.

I think its not only the question about the mix between people writing codes and writing fixes.. its about the focus as well.
No attention towards long time requested MIDI features. There is no sign whether Cakewalk has any plan for enhancing MIDI.
 
Regards
Snehankur

I hope the positive response to the fixes and optimizations in recent updates lead to them doing more. The only problem is then people will complain that there aren't new features, like an arrangement track.
 
Maybe the solution is even-numbered months = mostly bug fixes and optimizations; odd-numbered months = mostly new features. So something like fixing the long-standing remove silence issue would be a fix, and something like ACT 2 (which I would prefer to simply fixing the existing ACT) would be a new feature.

Anderton
I hope the positive response to the fixes and optimizations in recent updates lead to them doing more. The only problem is then people will complain that there aren't new features, like an arrangement track.
 
Maybe the solution is even-numbered months = mostly bug fixes and optimizations; odd-numbered months = mostly new features. So something like fixing the long-standing remove silence issue would be a fix, and something like ACT 2 (which I would prefer to simply fixing the existing ACT) would be a new feature.

That would be nice!
At least the bakers will get more time for thinking and developing something REAL new. Its not easy to think 12 new features, develop and deliver them within a year with a criteria of being 30days interval.
 
Regards
Snehankur

Having to work like that would drive me insane.
Some bugs may be easy, most will require some uninterrupted time to do properly.
Most effective is when the original developer fixes the bug.

charlyg
...And the program will also be obsolete in a few years as the competition passes it by with new features that SONAR decided the users didn't want(bug fixes only).

From my experience with other DAWs, Sonar is quite advanced by comparison. It owes it to itself to take a breather and go back to clear up the technical debt it has accumulated over the years.

I'd like to see areas blitzed with fixes and enhancements dealt with in conjunction. So for my bugbear (pun not intended) staff View, for the bugs to be identified, enhancement to be identified and for this to be implemented in a short time. Any new bugs related to this to be addressed within a few months whilst all the info is still fresh with the programmers. So with any given release, you'd think of it as the one that addressed staff view, or Piano role view, mix view etc.  So you get a balance between features and fixes at the same time. That in turn will create suggestions for for further changes, some easy, some requiring some planning. But with all the work fresh in place, it could inspire some further ideas from the bakers. We may have too wait 9 months to see these new changes, but in every given year of membership, you'd feel that every area became addressed. Nothing and no one felt neglected.
 
Some areas are bigger than others, so you may see a blitzing occur over several months for some areas. Of course if one area received a chunk of fixes and releases in month month, it would probably equate to several months in the background, with things being dealt with in parallel. 
 
I would like to see the program as a master of all trades, but it's a jack of a few at the moment.