Noel Borthwick [Cakewalk
]

bitflipper


It depends on what they've done with automation editing. I can't use X1 as it is today.

Automation rendering and editing has undergone huge updates in X2. The biggest ever update in 10 years to that feature area. We also fixed pretty much all the major issues that we knew about. Will write more about it when I get some more time. 
What specific issues prevent you from using automation in X1?

If you are talking about bugs in copying/pasting/moving automation lines for synths, this fix NEEDS to be pushed to Sonar X1 users. It is a FIX to a PROBLEM, not a new feature or convenience. I bought Sonar X1 thinking there wouldn't be a bug with this, but there was. And since I paid money for something I assume wasn't broken, I think I deserve a fix if one is available. If a fix does not exist, there is nothing I can do... but if it does, I really think it's unfair for you guys to force me to upgrade in order to get something that should have been included in the version I bought in the first place. Don't you agree?

Noel Borthwick [Cakewalk
]

Additionally you can drag and drop any VST into the PC and it will automatically turn it into an FXChain module in which you can then map your favorite params to knobs or buttons for quick access.
In some ways this is better than having the plugin in a bin since its a more compact representation of its UI.


Or you can drop in an empty fxchain module and use it as a cheap automatable gainstage anywhere within  the PC signal flow.

The more I read about X2 the more I am looking forward to its arrival.  Looks like you guys have really been listening to our needs on this FX issue in ProChannel.  This along with the neve/api/ssl console emulation will I expect make this update the best so far.  This update looks great in terms of workflow but also in terms of some new features (TH2 and console emulation).  Really looking forward to this one, which is something I cannot say I had about X1 prior to its advent.  I will jump in for the early adoption when it is available.  Can't wait! 

vaultwit

Noel Borthwick [Cakewalk
]

bitflipper


It depends on what they've done with automation editing. I can't use X1 as it is today.

Automation rendering and editing has undergone huge updates in X2. The biggest ever update in 10 years to that feature area. We also fixed pretty much all the major issues that we knew about. Will write more about it when I get some more time. 
What specific issues prevent you from using automation in X1?

If you are talking about bugs in copying/pasting/moving automation lines for synths, this fix NEEDS to be pushed to Sonar X1 users. It is a FIX to a PROBLEM, not a new feature or convenience. I bought Sonar X1 thinking there wouldn't be a bug with this, but there was. And since I paid money for something I assume wasn't broken, I think I deserve a fix if one is available. If a fix does not exist, there is nothing I can do... but if it does, I really think it's unfair for you guys to force me to upgrade in order to get something that should have been included in the version I bought in the first place. Don't you agree?

+ 1,000,000


I also made a thread specifically about this issue.


http://forum.cakewalk.com/tm.aspx?m=2645781

 "I really think it's unfair for you guys to force me to upgrade in order to get something that should have been included in the version I bought in the first place. Don't you agree?"


Nope. Following that logic Cakewalk would have to add all bug fixes available to all previous versions of Sonar. Good idea?


If it is so important to you, upgrade.

backwoods


 "I really think it's unfair for you guys to force me to upgrade in order to get something that should have been included in the version I bought in the first place. Don't you agree?"


Nope. Following that logic Cakewalk would have to add all bug fixes available to all previous versions of Sonar. Good idea?


If it is so important to you, upgrade.

Ok buddy. Following your logic, Cakewalk can intentionally plant bugs in their programs so they can release a "fix" in a later version and force users to upgrade using that.

How would you feel if you found out Apple purposely includes bugs in their iPhone models just so they can release a "fix" in their next model and force upgrades that way? They would've gone down a long time ago. In fact, every time there is an iOS upgrade, Apple releases a version of the new software to all prevous iPhone models. That way, an iPhone 3GS user is not FORCED to pay and upgrade to an iPhone 4 because of functional issues that keep them from properly using their phone. Unless a very old model iPhone physically cannot support the new iOS due to its processor and memory limitations. If it is physically impossible for Cakewalk to get a fix for this bug to Sonar X1, then fine. But I doubt that's the case.

Let's say you just recently found out that your 2011 Honda Accord has a serious malfunction in its airbag system, thougt you have been fortunate enough not to experience it in an accident thus far. If you take it to a Honda dealer, do you think they will say "sorry, you have to upgrade to a 2012 Accord in order to get properly functioning airbags." No, that would be absurd. In fact, I bet you can even take a 1992 Accord to the dealer and get the airbag fixed if it had that problem. Assuming it was legally purchased at the dealership, of course. If my Sonar was an illegally downloaded copy, I would have no right to complain about its bugs. But I paid for it.

Even to this day, Microsoft regularly issues Windows Updates for its Windows XP OS to fix any problems it may develop. Even though it has been superseded by Windows Vista, Windows 7, and soon Windows 8. Why? Because people still USE Windows XP. Just like many people will still be using X1. Microsoft announced that they will stop issuing updates for XP in 2014, but they have warned users well in advance. Plus they did not do this to Vista, nor will they do it to Win7 anytime soon. If Cakewalk stops supporting Sonar 3, I'm fine with that. But maybe Sonar 8 or 8.5, they should continue supporting. X1 most DEFINITELY.

So, you'd be perfectly happy if these enhancements were NOT included as part of X2 yes?

This is a common question/misconception so I will try and answer it. The analogy to companies like Microsoft and Apple are not comparing apples with apples. Cakewalk is a microscopic in size as compared to these companies, and we don't write operating systems that require periodic updates to support the platform. Its a completely different business model.

The retail software model includes one product cycle worth of updates. This is common to most companies and not just Cakewalk. We released 4 updates to X1 spread out a year and a half after the release. These included hundreds of fixes and even some new features from ongoing work in X2. The last update was X1D after which we focused our efforts entirely on X2. In this model its simply impossible to continue updating earlier product releases once a new product is released. What might not be obvious to those outside this industry, are the costs involved. The assumption that if a problem is fixed in a new release its easy to move that into the older release is incorrect. Many of the issues addressed in a new version are deeply entrenched in deeper design changes or even newer features that don't exist in the earlier version. Moving these to an earlier version would take months of regression testing since they are likely to introduce new problems living in a different environment. It would also drastically slow down development of new versions.

In X2 we committed ourselves to addressing user reported problems on equal footing with new features. Our upgrade prices are incredibly affordable for the value you get. There isn't a lot more we can do beyond this.

Noel Borthwick [Cakewalk
]

This is a common question/misconception so I will try and answer it. The analogy to companies like Microsoft and Apple are not comparing apples with apples. Cakewalk is a microscopic in size as compared to these companies, and we don't write operating systems that require periodic updates to support the platform. Its a completely different business model.

The retail software model includes one product cycle worth of updates. This is common to most companies and not just Cakewalk. We released 4 updates to X1 spread out a year and a half after the release. These included hundreds of fixes and even some new features from ongoing work in X2. The last update was X1D after which we focused our efforts entirely on X2. In this model its simply impossible to continue updating earlier product releases once a new product is released. What might not be obvious to those outside this industry, are the costs involved. The assumption that if a problem is fixed in a new release its easy to move that into the older release is incorrect. Many of the issues addressed in a new version are deeply entrenched in deeper design changes or even newer features that don't exist in the earlier version. Moving these to an earlier version would take months of regression testing since they are likely to introduce new problems living in a different environment. It would also drastically slow down development of new versions.

In X2 we committed ourselves to addressing user reported problems on equal footing with new features. Our upgrade prices are incredibly affordable for the value you get. There isn't a lot more we can do beyond this.

I completely understand where you're coming from, but I think a big part of the issue as it pertains to the specific problem of copying/pasting synth automation is that it has been a known bug/broken feature since the initial release of X1 and was never addressed in any of the updates or quick fixes. 


In my other thread about this topic, you'll see that I provided you some additional threads for reference where others bring up the issue and you'll notice that this problem has even come up as far back as '08.  So it appears Cake has had this same issue before, in a previous version.  8.5 maybe?  I'm not sure.  So this is not new territory for Cakewalk.  But from what I've read it seems it was fixed back then, temporarily, only to be broken again in X1.


As long as this problem doesn't persist in X2 I'm leaning toward upgrading for other reasons aside from the one presently being addressed, however I can definitely understand someones frustration w/ having to upgrade just to get a fix for a somewhat basic (imo) function.  Especially when it is actually a recurring problem that has been broken and fixed before.  

I can confirm that the amount of resources needed to maintain every past version of a program is prohibitively huge for any organization outside of the federal government or Microsoft. You'd need twice the staff to keep doing that, and the cost of it would have to be built into the product's price. SONAR 4 might still be getting bug fixes, but you'd have paid $5,000 or more when you first bought it.

That said, I do think it's not impossible to give some attention to previous versions, at least to the most recent predecessor. Many companies, even very small ones, do manage to support two versions at a time.  Each new version is not a rewrite from scratch, but shares a great deal of code and components with the previous version. 

If, for example, cronus.dll ever saw a fix release, why not make that fix available to users of previous SONAR versions that share it? You can make no economic argument against such a policy, save one: withholding compatible fixes is a tactic to coerce encourage upgrades.

Some of the automation issues took many days to resolve and weeks to regression test and find all the potential problems they themselves could cause. All of this was impossible to do in the X1 schedule timeframe or we would have included them in one of the updates if so. Some issues literally had changes over a 4 month timeframe to cover all cases. Automation is one of the most complex areas of the program - especially the issues related to editing. So they required a concentrated effort over a full product cycle to properly address some issues.

When a fix is in an external component we sometimes do make it available to prior versions. Its pretty rare that its that isolated though. Even if a fix was relatively minor to the main app executable you have to take into account the fact that we have to make an installer, regression test it and support it all of which takes resources.  Though this might look trivial on the surface its surprising how much time even a one bug hotfix takes to from conception to delivery. You can't just drop an executable out there when your userbase is composed of people with varying computer skills.