KPerry
Indeed, that would not be a stupid thing to do :-) Still needs work, as you have to compete with what people are used to (like I said, it's like 0-60mph figures for cars...they may be unhelpful, but they're a well-known reference point). But as I said originally, that's a perception that needs to change, so we're agreeing that performance is a perceptual issue, even if not an actual one.
Indeed we are agreeing. Cakewalk if you are there, get some comparison benchmarks going!
Doktor Avalanche
2) Plugins apart from buggy plugins work perfectly well. Just because Acoustica says so (URL?) does to mean to say it is true. Frankly I doubt it when thousands of plugins work perfectly well..
Doktor Avalanche
You've given us the URL to the thread, this is the interesting post within it however:
http://forum.cakewalk.com/FindPost/3236581
If Cakewalk haven't had any contact you can't blame them. Who know maybe afterwards it happened and things got smoothed over. Nobody can assume however there is a problem with Cakewalks code here from this information.
KPerry
Er...actually, I think you can. There is a definite implication that SONAR bounces/bounced threads between cores which is i) unusual and ii) definitely not good for cache locality and hence performance (that's an unarguable fact of multi-threaded processing). The latter is reflected in the general statistics and reports that show SONAR is/was significantly worse performance-wise than other applications (still, not just SONAR 7 on XP).
No you can't because there is no hard evidence... you don't know:
a) If it is a real problem.
b) If it's a perceived problem from Acustica or not. I would be expecting a lot more complaints than just one third party for instance.
c) If it was an issue that has already been fixed.
.. and you don't have any code in front of you to draw conclusions, or any studies to prove otherwise.
Doktor Avalanche
3) Sonar is reliable. It's people's systems that are unreliable. What is Cakewalk going to do gag these people who scream at great heights crying wolf? Admittedly there are still very visible bugs that need addressing (how long must I go on about that) but they aren't stability issues.
KPerry
Well, I find is reliable. But when you hear repeated stories (not on this forum) of SONAR glitching with 2 audio tracks, no plug-ins, or crashing when other DAWs don't, you have to understand that this is what perceptions are. Sure, it might be for good technical reasons (I think the Bakers code more by the book than others, which is why there are more VST incompatabilities than with others who just get VSTs to work like Cubase!), but that's not really something that bothers end users: why spend days troubleshooting something trivial when another application will work with no effort?
Doktor Avalanche
As I've stated, when there are serious stability issues these forums go beserk about the same thing with reproducible steps. All we see right now is stability issues with specific PC configurations. If there are issues with third party VST code Cakewalk cannot be called out for that, bare in mind the vast majority of VST's work fine. I think the actual problem is that third parties are testing their code with cubase but are not with Cakewalk, again no fault of Cakewalks. If the plugin claims to support Cakewalk they should bloody well test it under the platform IMHO. Users should be writing to the third parties and ask them how they do their QA under Cakewalk, is it just a matter of waiting for customer complaints and fixing them?
KPerry
I'm not referring to these issues: look outside these forums and you'll see general stability/reliability issues that affect users on SONAR and not on other DAWs on the same hardware. It's tough, but the conclusion that gets drawn is that SONAR is finickety/unstable - there was an entire range of audio controller chips that SONAR wouldn't work on a few years back (DICE 2 IIRC) that nothing else had problems with. Why's that?
And, yes, there should be testing with SONAR in addition to Cubase, but that doesn't seem to happen, and we already see a number of plug-ins where SONAR isn't on their compatible list. Why is that?
That is just hearsay. All DAW's need VST's adjusted in some way to be compatible. Sadly there is no standard where a DAW can handle the threads on the plugin as a client. The plugin manufacturer may have different views on how threads should be handled, that's not to say Sonar is doing anything wrong and that's not to say the third party is doing anything wrong either. The plugin manufacturer does not have access to any DAW source code either so I'm tempted to put that on hearsay. Whether that's true or not this is a theoretical discussion because nobody has put forward the exact issue yet, just a generalised opinion which really is not very specific, no facts. Ultimately the Steinburg standard is what DAW's and plugins should be looking at.
As far as plugin's not support for Sonar, I don't know how many. Either:
1) Cakewalk isn't giving enough information to third party manufacturers and make life too difficult for them.
2) Third party manufacturers think they are not going to make much money from it.
3) Third party manufacturers are too lazy or don't have enough resources to test on Sonar platform.
4) They perceive (wrongly) that if a plugin works on Cubase it must work the same everywhere else.
My question would be, why do so many manufacturers successfully support Sonar, and some others can't, won't or fail. What's the difference between the two?
Doktor Avalanche
BTW the only way is to do it by the book. If Cubase screws up an implementation, and Cakewalk does not, Cakewalk should not be expected to bend their implementation to be like Cubase's buggy code, what Cubase should be doing is fixing their code. It would end up being a spagetti situation for third parties otherwise, i.e. what happens if Cubase then fixes their code to be like Cakewalk's again.
KPerry
Unfortunately, that's not how the world works. If 9 out of 10 DAWs are written to "behave like Cubase" and yours doesn't, then yours is de facto the incompatible DAW.
That may be a perception, but it's sure not how the world works as explained earlier. The ownership should be on the third parties to test on a DAW it is supporting before it is released. If it all goes wrong to scream Sonar does not behave like Cubase the third party is simply crying wolf IMHO. They need to bash their heads together away from the public forums.
The standard is the Steinburg VST specification (which may be flawed documentation), it is NOT Cubase. That is all developers have to go on. Other DAW developers do not have access to Steinburg's source code, they may have access to SDK's as well (which may in turn be flawed), but they sure can't turn it into Cubase.
I think one of the problems with the VST standard is that Steinburg own it, DAW manufacturers should really get together and do an open source standard, Steinburg owning all the jokers on this is not heathy in the DAW market.
(EDITED FOR TERRIBLE TYPOS)