35mm
Everyone has an opinion or a theory and that makes for great discussion. But all the people saying "who would want to buy old, buggy software?" clearly don't understand software development. See my previous comment for a more in-depth explanation, but in short, using the words 'old' and 'buggy' together doesn't make sense. Legacy code in software is still in there because it still works great and can't be improved upon. It's already had its bugs fixed years ago. Bugs get introduced when new code is added. It makes more sense to use the words 'new' and 'buggy' together! All software has bugs. That's unavoidable. Bug fixes are prioritized by their importance - how many users are affected by this bug? and of course commercial ramifications - is this known bug affecting sales?
Other people are adding to the myths by saying things like, "You would have to take on the Cakewalk dev team to be able to do anything with the software as only they know the code" That's not how software development works. The code doesn't exist in peoples heads. It's written down and to a programmer, it reads like a book. Providing you have the skills, you could jump right into that code and get working on it straight away, which is what new Cakewalk bakers would have had to do.
Like it or not Sonar's source code has a hell of a lot of value locked up in it - 30 years of developmental value. To make sense of that you have to understand that the software isn't the singular program that you run on your computer. It is thousands of modules, each of which can be taken out, rearranged, adapted and put into something else. If you were a software company tasked with building a DAW from scratch on par with Sonar, it would take you 30 years to come up with something that was 30 years out of date. The solution would be to start off with something that has already had most of the hard work done on it, strip out the modules, adapt them, add to them and compile it into a new product with a different name, new look, and different branding.
This whole thread is completely speculative but if you are going to talk about the software aspect of it, please make sure you know what you are actually talking about!
Well, here's a little insight for you. On two occasions, I reported seemingly trivial bugs which were nonetheless very annoying and should have been "no brainer" fixes. And I was told by the Bakers, "we're aware of this bug but to fix it would break other things in the program so we have no intention of fixing it."
One of them was a problem whereby you could not automate the on/off switch of an FX Chain in the ProChannel unless that particular ProChannel was open and visible in the console. I think the other one was that automation of the arpeggiator on/off button did not work unless the track in question was in focus.
Those were bugs I brought up on the public forum. My beta testing account is full of unresolved bugs from 2-3 years ago with very clear recipes that if I told you what they were, you'd think wow, how come they never fixed that. I won't go into those ones for privacy's sake, but suffice to say that if I mentioned them, you'd be surprised that they were ignored. I suspect they weren't fixed for similar reasons, i.e. because doing so would unravel a Pandora's box of issues.
Does that sound like robust, future proof code to you?