I agree 100% with the first part of post #16.

jsg

Danny Danzi


I saw some stuff early with X2, but so far for me, everything is in good shape other than a few crashes due to Kontakt...which has always been a thorn in my side. (Kontakt, just so you know, I hate you! LOL)

What amazes me about the stuff I read on here is....either someone has a bunch of weird stuff happening, or they are perfect or near perfect. I can tell you this....and I mean it sincerely, I don't know how Cakewalk handles their beta testing, but in the testing I do for companies I test for....we beat the living heck out of the stuff and try to break it any way we can. We had a release of something that was pretty popular where we on the beta team for that product and cycle felt wonderful. We couldn't make the thing act up no matter what we tried.

Some really skilled people on that team too. We released it and the next day, there were like 25 things that were found to be wrong. We went from feeling like we were awesome to feeling like we failed. Case in point....software is always going to behave differently for people depending on how it gets used. Even if you have 100 beta testers that know what they are doing....there will be 200 users that will use the product differently.

I'm not sticking up for Cake, or any of the companies that I test for...there are obviously problems or people wouldn't be complaining. The first step in fixing these problems is recognizing that they exist. The next thing...which is a nightmare....is finding the recipe to reproduce them so they can be recognized as legit bugs. Anyone that's ever been on a beta team can relate to that. It's not only frustrating, but can do your head in and make you think you're crazy. You see something happening to you as a blatantly obvious thing that happens to you religiously. Several others try to repro the problem and it doesn't happen. What do you do? Whay can THEY do if they don't see it? Trust me when I tell you, this part totally sucks!

For example, I like to always try to repro the stuff people complain about on these forums. If you ever see me post "yep, confirmed" it happens to me too of course. If I don't post anything, chances are I tried it and was unsuccessful....but I always try to reproduce just about every bug someone posts on here just because I'm curious and it usually only takes about 3-5 minutes to try.

If I were to take a guess at the problems people are reporting in Sonar, I would say the DAW itself has become a bit too sophisticated and in a sense, has lost its way. Sometimes "ground-breaking and innovative" can make something that was once great, go a bit astray. Though I have not had any of the issues reported here on my end, (Thank God) there ARE things that happen to me in X2 that didn't happen in X1 or 8.5.

A few examples: Certain plugins crash X2 that do not crash X1 or 8.5, issues with the new plugin manager at times...a few strange out of memory messages causing crashes that I have never seen before due to Kontakt, weird slip editing of clips, main power button on a PC track being disabled when it was saved as "enabled", tracks losing focus and not hi-liting or scrolling properly without clicking on them, screen sets not maintaining what was last saved/used....little things like that. No show stoppers for me other than the out of memory thing.

That said, I'm STILL not using X2 for any serious projects other than one I did last week since the bundle was sent to me using X2. Another thing I have learned which may be something for people to keep in mind. It could just be me, but I sincerely feel we should do this if at all possible for a while just until we know for sure...

Any project done in X1 should remain in X1. I've had too many issues with old projects being brought into X2. Anything done in 8.5, should remain in 8.5. When you do a project in X2, start it in X2 and name it "name of file X2" so you always know where it was created. I've noticed that any project created in X2, works well in X2 without any weird things other than my Kontakt issue and an old version of ARC crashing X2. But try that....no more old projects in X2. I really believe there is some truth to this even if it may be just on my end.

At any rate, I hope the issues can be sorted out whether they be due to the software or some sort of hardware anomaly if one exists. Speaking of hardware....here's one...not a show stopper, but something that has always bothered me that can't seem to be remedied.

Any Echo card ever made that I have, (Lalya 24/96, Gina, Audiofire Pre 8 and 12) cannot do a punch out in ANY version of Sonar from Sonar 6 to present without leaving a gap while "Allow Arm Changes during playback" is enabled. A gap will appear unless you use inputs 1 or 2. All other inputs produce a gap in punch out with ANY Echo interface. Though not a horrible thing, it only happens in Sonar. If this sort of hardware issue can occur, others can be culprits and it very well could change how they react with different versions of Sonar....you just never know.

At the end of the day, we just have to keep on reporting this stuff. If you feel you haven't received the right answer or no answer at all, it's pretty obvious what must be done. I found out about my Echo issue because one of the Cake staff was kind enough to figure it out for me. Will it ever be remedied in a future version of Sonar? I don't know...but at least the problem was found out, they are aware of it and at least I know it's not me or any of the 4 cards I was running.

The thing that makes this difficult is....there are quite a few of us that have been here a really long time. It's a bit hard to swallow that there were good versions of Sonar that worked, you take the plunge to the latest and greatest, and have nothing but road-blocks. The frustration is understandable on all counts. However, speaking for myself, the Bakers have never turned me away when I had a problem and I'm no one special.

I reported my issues like we're supposed to do and was assigned someone to help me. In just about all of my situations, I was fixed up and taken care of. If anyone else hasn't had that experience, I'm really sorry...but it's always worked for me. If at some point it no longer does, there are enough options out there to where I honestly wouldn't spend any time on this forum downing Sonar.....I'd buy a DAW that worked for me and would resume my business...but that's just me. Again, my sincere apologies for anyone having problems. I sure don't think you're crazy and can definitely relate to your frustration having been there a few times myself in the past.

-Danny

Danny, your post is logical and it does seem true that no matter how much a program is tested, there's going to be situations in which the programmers simply cannot plan for, hence one user or another will experience a bug.  And this is compounded by the many, many users who really do not know what they're doing and are not particularly adept at technology, troubleshooting and audio in general.  
 
But there's something else going on at Cakewalk that defies this reality:  They released a program that has a multitude of color options and most of the them do not work.  Cakewalk knows they do not work, they don't work on anyone's machine, and hence becomes a far different issue than a "bug".  This is is sloppy quality control, poor project management and/or questionable programming.  Most reputable software publishers would have either removed the color options that don't actually do anything, or they would have made sure they work.  This issue says a lot about Cakewalk's values and priorities, it says to me the company is going downhill and that perhaps they are simply not equipped to handle the complexity that a stable, professional level DAW requires.   I know that programming a DAW is not easy and there are bound to be a few bugs.  But the color option fiasco is a design flaw that Cakewalk let pass, not a bug, the color issue is not dependent upon the end user's setup or configuration.  It speaks volumes, at least to me, that this is not a company interested in producing serious software for serious musicians.  I just don't think a good company would make that decision. 
JG
www.jerrygerber.com
 
 
 

I always try my best to be logical Jerry...lol...sometimes it comes out as a rant though. That said, I totally agree with you. There are definitely some things that need to be looked at and I've been one of the first "color guys" to be on the front line ever since I read a statement from one of the Bakers that mentioned something along the lines of "we wanted you to record music, not sit around messing with your DAW". While I can understand that, I can't accept it.
 
I happened to ask someone on the inside the real deal with colors. I was basically told "adding them into the scheme of things will not be as easy as a Panu mod" due to all the stuff that has to be implemented in on that front. Where Panu can give us a mod that may have a bug and the guy will fix it in an hour, Cakewalk can't do the same thing within their business.
 
Whatever the deal with the colors is...it's something that goes deeper than "hey, just press the color button in the next code of update and they'll be back". At least that's how it was somewhat explained to me. I'm an image prostitute....I always have been. I wouldn't even use Reaper until I created a theme from a theme from a theme that made me tri-pod. LOL! So I'm with you there.
 
A bit off the color topic, I have always felt that the innovation in Sonar was more geared for going against our DAW competition over "listening totally to the people". Then we'll hear stuff like "Cakewalk is really just a small company" which in my mind tells me "ok, then listen to your small following that has been begging for things for years" ya know?
 
All of the above said though, this particular version has been pretty good to me. Other than the little things I listed in that other post, I've been quite pleased with X2a. The hard thing about this is...it seems with each release, we take turns with upsetting people. What was horrible for quite a few in X1, worked out well with X2. What was great for those in X1, now gives them issues in X2.
 
What really stinks is...when you work with another DAW for a bit, you miss those things in Sonar that are no longer there. I get that way when using 8.5. It's still my weapon of choice because the thing just doesn't crash on me no matter what I do. I barely even save when using it...which I know is totally stupid, but that's how good it works for me and how much I trust in it.
 
I need that trust in a DAW again. If it takes less bells and whistles to get me there, so be it, ya know? Most of us have our own "go to" plugs anyway. Heck, I was happy just having a Sonitus eq on every channel. That's still a darned good eq with more options than some of the stuff I've paid big bucks for and I use it all the time.
 
Anyway, I'm not sure what the deal is...but for sure X2 is definitely a sophisticated piece of software. When you get this in depth, there are bound to be issues for people. I've been pretty content with the quick fixes and patches Cakewalk has put out in a timely fashion. I think "the core Bakers" we all know and love, love us and care about our comments. But I sometimes think the suits in high places that are looking at it more as a product than something WE actually use....are the ones that need a reality check. I'd be willing to bet "The core Bakers" have their hands tied in certain situations and just shake their heads because they can't do a thing and want to. I say that because you can just tell how passionate they are when they come on here.
 
If you think about it....most times, in a day job situation, you only care about the quality work YOU do at your job. When you get too involved or too attached, you only make things worse for yourself. It would be all too easy for them to say "well, I do my job, do as I'm told, take my paycheck and well...so what to the masses and what they think about Sonar....I need to feed my family."
 
I've never gotten that impression from them. They don't have to hang out here and talk to us, but when they do, the passion is there. Anyone can see it....it doesn't seem fake to me. I just think their hands are tied and someone else is ruining what goes on with our beloved DAW at times. We can only hope for the best. I'm just glad I've been lucky with this release....but yeah, please give me my colors back and some tweaking options....and a gapless audio engine....and fix my punch out gaps...and...lol! I really can't complain...there's no reason to really. If I get enough, I won't bash Sonar.....I'll just move to another DAW. So far though, I'm content.....but hoping for some better improvements. :)
 
-Danny

Hiya, Danny. Good to see you posting a little more again. Thought we lost you.

Quick question which is somewhat related to this thread. I know you keep a few different DAWs around the studio for obvious reasons. I was wondering if you've played around with the new Cubase and if so what's your opinion of it?

The reason I ask is I may have a little more monetary leverage again soon and I was thinking of tucking away a little bit of cash here and there to add it to my arsenal. Now before I get dogpiled or whatever this is not to say I'd be giving up on Sonar because I most certainly would NOT do that. It has a ton of stuff I really like but I used to use Steinberg and for tracking and editing I found it a little more suited to my preferences. I'd use them in conjunction and/or use the right DAW for the right job. The current price for Cubase is actually quite nice at $500. The reason I avoided it when looking at options for my current set up last year was that it seemed to lack tools and instruments I wanted and I didn't want to have to spend an extra $1000 to get it doing what I needed as a one man band. I figure now that I have Sonar with all it's synths/effects and all the third party goodies I've acquired (like BFD, TH2, GR5, etc...) that now it might be a worthwhile investment at some point. 

That said... my primary concern is whether it's gonna be even MORE of a bugfest/broken features extravaganza than Sonar. The notation stuff in Cubase would really help with my teaching/writing (which as you know is important to me) as well as the tracking/editing workflow which I'm assuming will be as pleasurable (if not more so) as my previous Steinberg set up. Another bonus is when and if I ever get work involving other studios or deal with paying clients I can say I use Cubase and hopefully avoid some of the prejudices some might have against Sonar even if I do most of the work within Sonar.

Anyway, hope that makes sense and that you've been well and happy. Cheers, dude.

I was looking at the Cubase forums the other day Beepster (as I'm sure you've done) and one thing I've noticed is that while there do seem to be people who are having problems and finding bugs etc, they tend to be bugs of a more trivial nature, as opposed to people ranting about it being unstable and crashing all the time. So maybe it is indeed built on a more solid code base than Sonar. 

Hi, Sharke. Yeah I was poking around briefly there yesterday. The impression I got was that it could use a patch but I didn't see anything too catastrophic. However those guys seem to be thinking on a different level. That forum is very different and to be honest I didn't even really understand much of what the complaints were about. I'll have to make a point of going over there from time to time to see if I can get my head around stuff even if only for educational purposes. Not sure I'd start an account though... at least not until I had the program installed and ran into problems.

I like you guys. Ya'll are more real and personable. ;-)

guitardood

DCMonkey


Something I'm curious about is what happens when VST plugins and the Host app (ie: Sonar) are compiled against different runtime versions.

Exactly!  I'm sure that a lot of system flakiness could be traced back this, hence my argument for sandboxing apps.  At the very least, it would protect the O/S from getting hosed.




Best,
guitardood

Sorry for the late post, but I just started following this MS VC++ discussion...
 
Why is it then that there are some users who had X1d installed on their computer, installed X2, which seemed to be working ok, then patch up to X2a, and run into issues, so the go back to working in X1d because it is more stable / bug free.
 
If the MS VC++ libraries are the cause of the issues and affect Windows globally, why would X1d continue to function as it did initially?
 
Also Cakewalk themselves have said time and time again that there is no reason to uninstall a previous version prior to installing a new one.  You would think that they would be aware of the potential issues which could arise from if new libraries are deployed as part of each install.

guitardood


Just to add a little "why" to this:  Say Cakewalk is using version 1.3.0231 of the C++ libraries to develop Sonar and distribute that version's redistributable with Sonar.   Next you install VSampler (just a name I picked out of thin air) which hasn't been updated in a while and was written to version 1.2.812 of the C++ libraries and installs that version of the redistributable with VSampler, could potentially cause a problem.  Also, say you install SlickerThanSlicedBread Compressor which uses version 1.3.4821 of the C++ libs and redistributes that with their product, it will overwrite the versions used to create sonar and potentially create a problem.  This is not Cake's fault, VSampler's fault or STSB Compressor's fault. 

This is Microsoft's fault.  This problem has been plaguing windows systems since Windows95 with MSVCP versions being downgraded by installing older software or upgraded by installing newer software to the point that it sometimes breaks Windows as well as some previously installed application. 

They have sort of resolved this, somewhat, by at least providing different libraries for their major releases (i.e. MSVCP5 for version 5, MSVCP6 for 6,etc)  but unfortunately with bug fixes and windows updates, even a supposed sideways move from MSVCP7.231 to MSVCP7.243 could potentially break software if either a bug that was counted on is now "fixed" or a new bug was introduced. 

And to the doubters that say "it is not possible that installing sonar (or any other application which updates system-wide libraries for that matter) broke windows", think again.   This particular scenario makes it completely possible if a driver manufacturer wrote their driver software with MSVCP7.231 and now after sonar, it is MSVCP7.243 or any other possible disparity between the lib used to develop vs the currently installed runtime lib version, could potentially break their driver and/or service which could potentially end up in a BSOD and prevent booting. 

Again, not Cake's fault, not the hardware or manufacturer's fault, but good ole Microsoft.  But don't believe me.  Just do a quick google search for "msvcrt version resolved" or "msvcp version resolved" and read through some of the 1.2 million results regarding this particular issue.  I've been complaining about this for quite a while that sandboxing apps to have their required libs in their own space and leave the \windows\system32 versions alone, would probably resolve at least 25% of the BSOD's of the Windows world.  As would differentiating between drivers required for windows to boot (a la safe-mode) and drivers for other pieces of hardware which should loaded in a separate memory space and not be allowed to crash the entire operating system.  If I need my files, I don't care if the bluetooth driver has a problem, just get me to my files.  Unfortunately, instead of concentrating on these difficult to solve problems, MS presents us with Metro. 

Sorry for another rant in the same thread.  Just a real hot button issue for me.  Hopefully somebody appreciated the little bit of enlightenment. 

There are many evils lurking in the concept of "shared libraries" and I'd throw the registry in there as one of those "seemed-like-a-good-idea-at-the-time" scenarios that went badly wrong.  

I agree with sandboxing an app around versions of libraries that app has been tested to work with.  I also think that too much of the Windows OS is overly complicated around the notion of supporting multiple users, when in fact the majority of us are the one and only user at our machine.  

Really, in order to install an app should be pretty much a copy of a folder/directory, and it shouldn't matter where you copy it too when running the app.  That would make installation and uninstallation a snap.  I know there are grey areas around settings and configuration etc., but I believe if we return to that basic paradigm of a folder copy and sandboxing as much as possible then we'd all be better off (developers, testers, users, ...), and start with the assumption that this is one machine with one user.

Btw, I worked at a company where they insisted on writing all their own C++ libraries and steadfastly refused to include any off-the-shelf DLLs or SharedObjects.  It created a lot of extra work, at times it seemed unnecessary and redundant,  but I have to say we had exceptional control over our environment.  No longer were we, or our testers or users subject to being blind-sided by some updates to external libraries beyond our control, many of which contained updates that were of no use to us.

These days the pace of development is so fast, and the nature of open-source coding providing such a wide array of shared input and testing, that it's just a fact of life that you live with those code dependences.  But I wonder if DAW software is ultimately better off trying to do everything from scratch with no other libraries.  My programming expertise doesn't go into those areas, so I wouldn't know the level of effort or practicalities involved.  I wonder what development paradigm the other DAW software vendors follow?  It might explain why some feel more snappy and responsive at times ...?

==> I wonder what development paradigm the other DAW software vendors follow?  It might explain why some feel more snappy and responsive at times ...? <==
That was my next question. 

If anyone is interested in the final product of the song that caused all this heartburn, here it is:
Our Black Regalia

pbognar


==> I wonder what development paradigm the other DAW software vendors follow?  It might explain why some feel more snappy and responsive at times ...? <==
That was my next question. 

Hard to say. I think development philosophy/methodology has a big effect on 'buggyness'. I'm a firm opponent of 'Agile' methodolgies except for those few instances where it provides a genuine and distinct advantage. I've seen to many cases where the daily constant changes and the fixes to those changes and so on (ad infinitum) wind up with a badly architected mess.