I am convinced, that the bullheaded yearly release of a new version is the basic reason for stabilityproblems and continuing bugs. There is not enough time for bugfixing and basic corrective work, which is a big handicap compared to the competitions. Cakewalk/Roland should readjust the purchase price of sonar, give up the fixed release intervall, so that they have enough time/money to optimize the current version (1,5 to 3 years).
I am a new Sonar user (from Germany) and i have Sonar 7. I like the concept and the features of Sonar, but i am disappointed about the stability and reliability. If i read the stories about Sonar 8 - i must say - that i am in doubt about my decision for Sonar.
Cardamom

ORIGINAL: Cardamom

I am convinced, that the bullheaded yearly release of a new version is the basic reason for stabilityproblems and continuing bugs. There is not enough time for bugfixing and basic corrective work, which is a big handicap compared to the competitions. Cakewalk/Roland should readjust the purchase price of sonar, give up the fixed release intervall, so that they have enough time/money to optimize the current version (1,5 to 3 years).

Bingo. Cakewalk need at least one or two extra (in depth) patch update cycles per version. Add another two months of planning and design and that would probably bring the release cycle to 1.5 years instead of the yearly upgrade that happens now. Maybe two years. It doesn't need to be any more than that I reckon but of course I am just a guessing. One thing that isn't a guess is that the current release cycle does not work.


UnderTow

ORIGINAL: daveny5


Not a very Christian comment for someone with a fish as an avatar. Maybe you should hear their side of the story.

What about Muslims, Sikhs, Buddhists, Druids, Agnostics, Atheists etc?

Why pick on a Christian?

Why assume someone's faith, or lack of it, should affect the way they act as a consumer?

And how do you know he's a Christian?

The fish is used to symbolise many things, not just one specific belief system.

What does an avatar created from a still from a music store's CCTV camera showing some bloke loitering with intent say about its owner?

ORIGINAL: arkiruthis

ORIGINAL: SteveStrummerUK

What does an avatar created from a still from a music store's CCTV camera showing some bloke loitering with intent say about its owner?

*bing bong*
"Security to aisle 3 please, security to aisle 3"

You stirrer

ORIGINAL: John
You concur Undertow and without having Sonar 8. Odd don't you think? I am not saying you will be problem free with it but how can you agree that its bad without using it?

Sonar 7 is unusable for me. No new fixes will come for that version due to Cakewalk's one year cycle policy. Also, these kind of problems have been happening since Sonar 3. Every version of Sonar has some major issues that do not get resolved. Some times even recognised by Cakewalk themselves.

Also, I am basing my judgement on bugs being reported that have nothing to do with hardware or OS. (I'm not talking about the motorboating issue) and on some design decisions that perplex me. I do not need to have Sonar 8 to find the new split clips behaviour or the new aim tool (can't remember it's name) peculiar. Also I am comparing Sonar to the many other audio applications I use either at home or at the numerous studios I work at.

John, you should know by now that I don't make comments lightly. There are some good thought processes behind my comments. You should also know that I have a history in IT at various levels from engineer to management heading engineering and R&D departments. (Well maybe not but I have mentioned it quite a few times). I do speak from some experience.

Anyway, the results, Sonar, over the last few years speak for themselves.

What happened to being neutral when one has limited facts?

Are you referring to my comment about making feature requests? That is different. I want to have hands on experience with the software before I make suggestions. Often there are solutions or possibilities that combine various existing features within the software.

Here is a simple example: By combining the idea of nested folders and a feature to right click on a folder track to freeze/unfreeze all tracks within a folder you suddenly get the bonus of a feature to freeze/unfreeze all tracks within a project.
It doesn't need any new deep functionality. It just uses the existing underlying functionality but allows a new way of working. Combining features, if well designed and implemented, often create new powerful bonus features. The sum is greater than the parts...

So I will make suggestions when and if I upgrade to Sonar 8. That depends on how well the web demo performs on my system... (And a few other things).
UnderTow

However some have real issues but not because the program is inherently unstable or bug ridden.

You make too many assumptions John and claim them as fact way too often. There are many many long-time users who announce they have been long-time users of Cakewalk products telling you they have serious issues with this release and you and the "fanboys" if we're calling them that keep ignoring that this version is causing a lot of problems. Cakewalk even acknowledge the wave draw on recording was wrong and they'd fix it. This is a basic in any recording software and shows a rushed job in hitting their yearly "deadline". We love Cakewalk but crap it's hard to buy something that actually has more problems than any previous release. Many people are telling you they have built big stable powerful systems and run 7 religiously and moved to 8 and can't use it yet. Listen to them. It's not just newbies and your argument is based completely upon "must be people who don't know their systems as well as I do."

And quoting myself again....
I can't believe some people who think asking for a stable application means completely bug free.

No wonder people on other forums think some Cakewalk forum users are pretentious. They argue and argue without even listening once to others around them who are users JUST LIKE THEM.

About the Cakewalk development cycle ....

I used to speak with the Cakewalk folks (back when my day gig involved computer music research). At that time, Cakewalk had a steady one-year heartbeat development rhythm. Sure, some things cooked on the back burner for more than a year. But, in general, there were a series of milestones that started with planning, and ended with shipping. IIRC, the detailed planning activity started a couple months before the ship date for version N (around the time that final feature decisions for version N were made). Work in progress that couldn't make it into Sonar N might get retargeted for Sonar N+1 (or not, depending on circumstances). Stuff gets coded and alpha tested and critiqued and reworked, yada yada, and then beta tested, and reworked again ..... and finally (I'd guess) there's a heavy stabilization phase, and code freeze happens, and test gets their final say, and then final binaries are sent out for replication.

From everything I've seen over the past few years, it seems pretty clear that Cakewalk is still using a 1-year development cycle for Sonar. They ship like clockwork, every fall.

Having a heartbeat development rhythm is usually a pretty good thing. My own team uses 6-8 week milestones (I shipped 7 releases this year - but my app is a lot smaller than Sonar, and the differences between releases are much smaller than the S6-S7 delta, or the S7-S8 delta). Back in the day, I admired the Cakewalk development process a lot (especially compared to a lot of other music software companies I've seen, with far more haphazard development - and results).

Now, about the notion that Cakewalk might be working on Sonar 11 right now --- no way! Oh, there might be some long-range planning going on, but there's no way they're building code for Sonar 11 at this point. Things change too fast - operating systems, 3rd-party plugins, VST/ASIO specs, you name it. They need all their developer talent to focus on what's going to ship over the next year or so. If they focus too far out - they risk the business. (Of course, if they don't look far enough ahead, they also risk the business, but for different reasons.) Having said that, it's quite possible the V-700 work started a couple years ago -- but ramping up for a new product line is different from keeping an annual maintenance cycle ticking over.

Should Cakewalk adjust their process to ship a more stable .0 release? That seems quite possible, based on the history of Sonar 7 and 8. But, at the same time, I think one of the main problems may be the huge variety of system configurations out there. It's certainly not the only problem (a lot of things seem to slip through that shouldn't --- example: the lack of any regression testing for CAL seems very weird, given they still include CAL). But - different configurations are certainly a huge problem. In order to catch those kinds of things before the official .0 release, Cakewalk might need to do some kind of open beta program. Finding a business model that would support isn't easy (and I would really like Cakewalk to stay in business; not only do I think they're pretty good people, but they're still the best overall music app for the PC platform, IMHO).

About the OP's point ('beta culture has to change') - I'm actually in violent agreement. I despise software that breaks if you look at it sideways. Software that doesn't work reliably is pretty useless, no matter how cool it may look on paper (or on a webpage). When we launched Sequencer Plus (1985), a Mac app named 'Total Music' launched at the same time that, on paper, totally blew us away. It had way snazzier features -- we thought we'd go bust in a month. But -- strangely -nobody could get TotalMusic to work reliably. At all. The thing was horribly bug infested. Most of the features didn't actually work at all. As for us - we'd focused hard on making the core app stable, and deferred the features we didn't have time to get right. We won awards (and lots of customers); they pretty much disappeared.

These days, I think it's a lot harder to focus on getting the fundamentals right (for lots of reasons). I give props to the Bakers for spending the effort on the Sonar 8 audio engine redesign (even if it's not quite right yet, posts indicate that it's been a major improvement for many users). I don't have S8 yet myself - because I'm not doing enough music to justify it. Once I get a couple of pieces actually finished, I'll upgrade. Until then, I'll lurk and learn - I usually wait until at least the .2 update before I upgrade, in any case.

My 2 bits,
Jim

ORIGINAL: John

the detailed planning activity started a couple months before the ship date

How the heck is that possible? What the heck are they doing the rest of the year? That makes no sense at all.

Well, it all depends on your process. How much software development have you done? And what kind?

IMHO, starting detailed planning more than a couple of months ahead - is just a waste of effort. Too much changes by the time you get down to implementing stuff. Instead, I prefer more general planning ("where do we want to be in 1 year? In 2 years? In 5?") and then do the detailed planning in smaller chunks, "just in time" for it to be useful.

My current team uses an 'agile' process. We use 6-8 week milestone periods. We do detailed planning the first week of a milestone. Code is usually frozen 10 days before the end of the milestone. During the last week, we review what worked (and didn't), and do bugfixing if anything critical slipped through (other bugs are fixed in the following milestone).
The revew results feed into planning for the next milestone (which starts the next week).

There are lots of ways to build software. Unfortunately (IMHO), the most common way people think about it (especially people who don't actually do it!) is using the old "waterfall method" -- all the requirements are gathered first, then all the planning gets done, then all the code gets built (in one huge chunk!), then all the testing happens, then bugs get fixed:

Requirements
     --> Planning
          --> Design (if you can talk management into it... and you'd better; it's vital)
                --> Coding
                        --> Testing
                              --> Bugfixing
                                       --> SHIP !!

Well - that works fine for a 6 week milestone. For a 1-2 year application project - it stinks (IMHO).
"People who use the waterfall method fall off the edge - and it's a long way down"
(There's plenty of software people who agree with me, btw, and a few that don't, of course )

Getting back to describing the (hypothetical) Cakewalk approach - I said detailed planning happens the last couple of months before the cycle restarts. Do they do some planning earlier? Sure, but it's got to be more general. Marketing is putting together feature lists, management is managing final stages of the current cycle - and lots more, of course. "What the heck are they doing the rest of the year?" They're hardly sitting on their hands.

Personally, I'd be laying out 'major goals and feature bullets' for the next rev, oh, six months ahead (and talking with marketing before that, of course). But I wouldn't start really detailed planning for an upcoming release until I knew what was solid in the current release under development, and how my team was doing (strengths and weaknesses), and what the burn rate actually turned out to be for various kinds of work.

These days, I do more R and less D (I'm in a research lab, after all). Right now, we have a very general idea of where my team would like to be at the end of 2009 (well, employed of course, but besides that....) But, we have a lot of inventing to do before we know what we'll really have to deliver to our customers (other people in the company who actually use our stuff). We have a lot of prototyping, and user studies, and false turns, and recoveries ahead of us - and hopefully a few real insights along the way. If I was building commercial music software these days, I'd approach it at least a bit differently. But, even there, I don't buy the notion that you plan everything up front and then just turn the crank for months and months. It doesn't work that way.

- Jim

Hello,

the often said 1 year cycle. We have no idea how CW programs. It could be 1 year or 3. When they start a new version it is the project start that counts and it could be a 3 year span. We don't know. They could be starting work on Sonar 11 now.

The idea is it could be any time span that CW has as its way of projecting future release dates. Just because it appears every year is no reason to say its a one year cycle for the development.

I was careful to say that Cakewalk has become a slave to it's a 1-year "update" cycle. I was careful not to use "development or programming cycle." There could very well be parts of Sonar that are in constant development. For instance, the audio engine. There could be an audio engine team that does nothing but optimize the audio engine and whatever is ready when it's time fior a new release gets incorporated. The development schedule is not what counts. It's the 1 year cycle that controls. No matter what they have when that release date comes around they have to start shipping DVDs. So it is more likely that there are teams that constantly work on the core features of the program and teams that are developing the "goodies." They can be developing a goodie for 2 or 3 releases from now. I wouldn't doubt it. However, when push comes to shove when that yearly release date arrives, they must push a product out the door and that product will get the improvements that are available.

The schedule has to be longer than 1 year because you have to allow for alpha and beta testing, duplicating and stocking the fulfillment houses for delivery to the disti or retailer. But it is still a 1-year release cycle. This is not true for other software products in this space - Sony and Steinberg products to name a couple.

The real significance of a 1-year cycle can be understood this way: no matter how much you test, alpha test and beta test, you do not know what you have really done until you start selling the product in quantity and receive the true feedback - from the field. I'm sure with a piece of software as complicated as a DAW host, when a new product is released, the programmers are cringing in their cubicles at every phone call into tech support wondering if some really bad bug got past everyone and is going to trigger a flood of "trouble." Everyone breathes a sigh of relief when the new release "sticks," that is, customer satisfaction is high and there is no flood of customer support calls or, worse, complaints and returns at retail. I am dramatizing but you can get the idea. It is from years of having a product "in the field" that the developers have learned to make a product with a high degree of satisfaction. The learned this not from the alpha or beta testers or even from the top pros who lend their expertise. They learned it from their rank and file customers. That is the proof the product works.

So when you release each year you only get one year of feedback from the field and you only get one year to correct glaring errors - no matter what long-term development is in the works.

Another issue for me is Sonar 4 seemed like a watershed version. Because it was so (for me) I decided that I would venture to V5 which I did. Now with 5.2 I feel I have tremendous capability but certainly not unlimited capability. When V6 was introduced I didn't see that there was anything that 5.2 couldn't do just interface tweaks. So I passed on V6. When V7 came out, once again I didn't see how you could record audio or midi any better than 5.2 and I didn't see that you could do very much different in terms of editing existing clips. So once again I passed. It wasn't a question of money; it's a business expense for me. When V8 came out, I realized I had (not intentionally) broken the Sonar upgrade habit. It wasn't that there aren't some really cool things in V8 compared to my "long-in-the-tooth" V5.2, it's just that it doesn't "float my boat" so much anymore and, once again, V8 can't really record audio or MIDI and manipulate it any better than what I have. Using 5.2, in the past year I did a full symphony orchestra project with 30 tracks of Garritan GPO. I've also did a 20 track audio project and also a sound effects montage that I would normally use WaveLab for. I don't have cutting edge equipment just a lowly dual-core. I can’t see how any of the subsequent versions to 5.2 (and really that is V4) would have improved my experience on these projects. And for using 5.2 for a number of years, I am comfortable with everything it can and can’t do on my setup. So I never encounter the “surprises” that one gets from pushing a setup’s capability. Version 5.2 has become the “devil I know.” I am reluctant to change a nicely working system even though Version 8 comes with a lot of goodies, I have to admit. In the end I value stability over increased capability and goodies. Now V8 may be just as stable as 5.2 but then that is no improvement or reason to upgrade.

Cakewalk’s de-facto yearly subscription is like a poker game – you have to continue to pay if you want to play. Because they add goodies in one release that may not be in subsequent releases if one decides to skip a release (e.g., “fold their hand”), you will not get a chance at that goodie in the next release. I find that marketing ploy to be insulting.

The next Sonar upgrade for me is probably years away when Window 7 is so ensconced that XP and Vista will be memories. Hopefully there will be a real reason to upgrade then.

GK

My current team uses an 'agile' process. We use 6-8 week milestone periods.

Hello,

A good definition of a programmer is a professional who does not have a healthy respect for "Murphy." It's 7:00 p.m. and I'm leaving for the day. It's my company and tomorrow at 10:00 a.m. we have a huge dog and pony show for our customers and we are showning the new prototype. So I ask the programmer how is it going (we had an important new feature that had turned out to be difficult to implement, but was nearly solved). His reply was all was well and he had "just a couple of more hours work." The next morning I arrive at the office 7:30 a.m. (with the requisite bagels, donuts, fresh pastry, fresh squeezed OJ, etc.) and the first thing I smell when I open the door is burnt coffee. I go into my programmer's office and there he is frazzled to the core, sitting in the midst of his 3 computers and laptop in a pile of Coke cans and every coffee mug from our kitchen banging away at the keyboard. No, I did not have my new feature for the dog and pony show.

And that is every programmer I have ever worked with. That bug, that feature, no problem! I just need [2 hours/2 weeks/2 years] and it'll be done. [Repeats] "No Problem!" To which my reply has always been "from your mouth to G-d's ears."

GK