Cakewalk Sonar X3

[arachnaut]

...Sonar registers the VSTs into the Registry like it does with DX plugs, and it uses the file name, rather than the VST ID, to differentiate them. ...

This was changed in Sonar X2a and completely rewritten in Sonar X3.

X2:

http://www.cakewalk.com/Support/kb/read ... 2007013302

X3:

http://blog.cakewalk.com/developer-note ... ancements/

[flugel45]

....

A far as i'm concerned, it still behaves like a wrapper..... i've ranted about this extensively on KVR and on the Cakewalk forum in past, so i'll spare everyone this time.

Too late. Or is this your idea of sparing everyone your rants?

Anyway, isn't this thread supposed to be about X3? Not "Issues I've had with past versions of Sonar, and more importantly, the CW devs never listened to me!".

Start your own thread about being disgruntled if you must. But until you upgrade to X3 (And you've made it abundantly clear it's not gonna happen), please adhere to your own promise and spare us any further rants about it in this thread!

[ObsoleteAcc99]

[DELETED]

[noelb]

Hi folks,

I hang out more on our forums so pretty rare for me to post here.
There has been so much gross misinformation circulated on this topic that after a while it becomes urban legend
Anyway I'll try and set the record straight for the umteenth time! This is long winded but hopefully will cover all the common issues that are misrepresented.

Eons ago Cakewalk had excusively DX plugins and SONAR's engine itself was DirectShow based. This was completely redesigned from scratch back in 2003 when we did SONAR 3. Ron and I essentially rewrote the entire DX engine from scratch using a custom designed streaming model and graph. The main reasons for doing so were manifold. While DirectX was pretty sophisticated at the time for more general purpose streaming, isn't wasn't flexible and simple enough to handle dynamic audio bussing and a more plugin centric environment. So we replaced it all with a much simpler, compact and scalable design, something that has survived almost 10 years of development.

At around the same time or shortly after we replaced the plugin code with our own plugin abstraction layer. Irrespective of plugin model, whether it is VST, DX, AU, AAX etc, all plugins share some pretty common operations so our plugin abstraction layer implements a common interface that is shared by all plugins. Pretty much all modern DAW and plugin vendors use the same approach. For any application that needs to support multiple standards, it would be pretty shortsighted to put all your eggs in one basket and base everything off any one standard that can change beneath your feet. So in essence SONAR's engine talks to our abstraction layer which in turn talks to the specific plugin protocol implementation. I've talked to a several vendors over the years and they all use a similar if not identical approach. Its this approach that actually allowed us to implement VST3 relatively easily. If hypothetically our internal protocol had been pure VST2, it would have been a complete nightmare for us to do VST3, since there is really nothing similar between VST3 and VST2. If anything ironically VST3 looks closer to DX to me with its COM like component design

Finally regarding our VST scanner - SONAR uses a standalone scanner to prevent the scanning process from crashing the DAW. It also allows us to do some of the cooler stuff that we're doing in X3, like background scanning. The scanner unlike SONAR itself is 100% native VST, since its essentially a very simple app that talks to the VST and queries it for all its relevant properties. All the properties are stored in the registry in a similar way to how the old FXPansion scanner did. We chose to retain the original GUID based identification scheme for VST's, primarily because it allowed us to retain backwards compatibility with all SONAR projects created earlier. There was some shortcomings with the original GUID scheme, since it relied on the short file names of the VST's (as well as the VST ID's obviously). This occasionally caused problems when short file names changed on the system, leading to various problems. This issue was finally put to bed in X2, when I changed this scheme to use a more failsafe approach. We still store the old format guids for backwards compatibility but all newer versions of SONAR since X2 use the new GUIDS. Interestingly VST3 also abandoned the old VST ID approach and now uses GUIDS (what Steinberg calls FUID's). This actually fit in perfectly with what we have been doing all along and as a result I didn't have to change anything in our storage format.

So to sum up this long winded explanation. The answer to the question to whether SONAR uses a DX wrapper, the answer is no. We use our own internal plugin abstraction layer for ALL plugin formats we support - DX, VST or VST3. If we need to support a new format (God forbid!) in the future, we're ready to do so. All that's needed is a new protocol implementation.

Now can we put this urban legend to bed?

If after this diatribe you still up for more boring technical reading, here are two blog posts about SONAR X3's plugin enhancements.

http://blog.cakewalk.com/developer-note ... ancements/

http://blog.cakewalk.com/developer-note ... tegration/

cheers!

--
Noel Borthwick
CTO,
Cakewalk

[Ryan99]

....

A far as i'm concerned, it still behaves like a wrapper..... i've ranted about this extensively on KVR and on the Cakewalk forum in past, so i'll spare everyone this time.

Too late. Or is this your idea of sparing everyone your rants?

Anyway, isn't this thread supposed to be about X3? Not "Issues I've had with past versions of Sonar, and more importantly, the CW devs never listened to me!".

Start your own thread about being disgruntled if you must. But until you upgrade to X3 (And you've made it abundantly clear it's not gonna happen), please adhere to your own promise and spare us any further rants about it in this thread!

I agree with you. I followed this thread for a while and I'm really tired to read the same complaints over and over about previous versions of Sonar. Nothing personal against those people, but please move on, you made your point abundantly clear.

Respectfully yours, let's hope X3 will finally be the positive answer to your complaints.

[mgpqa1]

Hi folks,

I hang out more on our forums so pretty rare for me to post here.
There has been so much gross misinformation circulated on this topic that after a while it becomes urban legend
Anyway I'll try and set the record straight for the umteenth time! This is long winded but hopefully will cover all the common issues that are misrepresented.

Eons ago Cakewalk had excusively DX plugins and SONAR's engine itself was DirectShow based. This was completely redesigned from scratch back in 2003 when we did SONAR 3. Ron and I essentially rewrote the entire DX engine from scratch using a custom designed streaming model and graph. The main reasons for doing so were manifold. While DirectX was pretty sophisticated at the time for more general purpose streaming, isn't wasn't flexible and simple enough to handle dynamic audio bussing and a more plugin centric environment. So we replaced it all with a much simpler, compact and scalable design, something that has survived almost 10 years of development.

At around the same time or shortly after we replaced the plugin code with our own plugin abstraction layer. Irrespective of plugin model, whether it is VST, DX, AU, AAX etc, all plugins share some pretty common operations so our plugin abstraction layer implements a common interface that is shared by all plugins. Pretty much all modern DAW and plugin vendors use the same approach. For any application that needs to support multiple standards, it would be pretty shortsighted to put all your eggs in one basket and base everything off any one standard that can change beneath your feet. So in essence SONAR's engine talks to our abstraction layer which in turn talks to the specific plugin protocol implementation. I've talked to a several vendors over the years and they all use a similar if not identical approach. Its this approach that actually allowed us to implement VST3 relatively easily. If hypothetically our internal protocol had been pure VST2, it would have been a complete nightmare for us to do VST3, since there is really nothing similar between VST3 and VST2. If anything ironically VST3 looks closer to DX to me with its COM like component design

Finally regarding our VST scanner - SONAR uses a standalone scanner to prevent the scanning process from crashing the DAW. It also allows us to do some of the cooler stuff that we're doing in X3, like background scanning. The scanner unlike SONAR itself is 100% native VST, since its essentially a very simple app that talks to the VST and queries it for all its relevant properties. All the properties are stored in the registry in a similar way to how the old FXPansion scanner did. We chose to retain the original GUID based identification scheme for VST's, primarily because it allowed us to retain backwards compatibility with all SONAR projects created earlier. There was some shortcomings with the original GUID scheme, since it relied on the short file names of the VST's (as well as the VST ID's obviously). This occasionally caused problems when short file names changed on the system, leading to various problems. This issue was finally put to bed in X2, when I changed this scheme to use a more failsafe approach. We still store the old format guids for backwards compatibility but all newer versions of SONAR since X2 use the new GUIDS. Interestingly VST3 also abandoned the old VST ID approach and now uses GUIDS (what Steinberg calls FUID's). This actually fit in perfectly with what we have been doing all along and as a result I didn't have to change anything in our storage format.

So to sum up this long winded explanation. The answer to the question to whether SONAR uses a DX wrapper, the answer is no. We use our own internal plugin abstraction layer for ALL plugin formats we support - DX, VST or VST3. If we need to support a new format (God forbid!) in the future, we're ready to do so. All that's needed is a new protocol implementation.

Now can we put this urban legend to bed?

If after this diatribe you still up for more boring technical reading, here are two blog posts about SONAR X3's plugin enhancements.

http://blog.cakewalk.com/developer-note ... ancements/

http://blog.cakewalk.com/developer-note ... tegration/

cheers!

--
Noel Borthwick
CTO,
Cakewalk

Interesting read, thanks for that! I always appreciate it when the actual people who create the tools that we use take some time out of their busy schedules to chime in.

[bbaggins]

Is X3 truly a completely native vst solution.. Some have said otherwise about previous versions.. So can you please give a definitive answer on X3 one way or the other?

What would you accept as "definitive", short of access to the source code?

VST has been natively supported since SONAR 6 (2006).

More important, what's the diff? Every DAW has an abstraction layer (read: interface, or if you prefer, "wrapper") between its audio engine and plugins, regardless of the DAW or the plugin format. The whole "wrapper" question is irrelevant.

[icontakt]

I'm SO glad to see Noel chiming in KVR and explaining.

[Jace-BeOS]

Nice to have these answers. But, yeah, too late, Cakewalk. If you had done it right the first time, i wouldn't have all these rants in me from suffering the product's various freaky behaviors.

Is Sonar still staying silent when you delete a soloed track? How about proper instrument tracks, rather than the freaky hack of grouping a MIDI and audio track into one mutant track-alike thing? Got smooth scrolling in there anywhere, or do we still have to deal with jumpy views when scrolling stuff?

New features don't matter when the existing ones are so poorly executed. When you do it wrong and then make people suffer for years more before re-doing it right (and charging them for access to the done-right versions)... well... you lose people by attrition.

As for flugel45 and Ryan99, this is all relevant discussion; Cakewalk has been selling this product in its various states of broken functionality for many years and this has shaped a long history worth examining. They ought to expect old users to share their experiences with new (and potential) users, when discussion starts of new versions that Cakewalk hopes to make money on. For anyone who is considering getting on the Cakewalk train, here are some former users telling them what the history has thus far been. A product's history tends to predict its future, and the Cakewalk history is littered with debris. New version? Big deal. New owner? So what? The product has spoken, and it's not as pretty as the marketing.

[hibidy]

Ok, stayed out for a while. Yeah, broken features, etc etc.........

Ummmmmmmmmmm, what is the ACTUAL word from those that are using it???????????

[Jace-BeOS]

No one is using it yet, right?

EDIT: isn't that why this is essentially a Bitwig-ish thread?

[Proteinshake]

I've never seen a "Pro" using it.

[trimph1]

Well, one can check the CW forums...seems a good barometer I'd think. Seen a few SUEs there...

[whyterabbyt]

I agree with you. I followed this thread for a while and I'm really tired to read the same complaints over and over about previous versions of Sonar. Nothing personal against those people, but please move on, you made your point abundantly clear.

The problem with that is that some people are invested in making those complaints, whether they make sense not. Witness the repeated posts by the guy ignoring the big additions of VST3 and ARA, to complain 15 times about there being bundled plugins, because the very existence of them is an affront. Even Noel's lengthy post responding to the 'wrapper' nonsense is not the first time he's explained this; its been made clear several times by CW people that that's not how Sonar has worked in a long time, and some people have been pointing to those explanations in Sonar threads just as long, including to people who are in this thread now saying that it still uses a wrapper. Witness the people that dont understand how software abstraction works, but who 'know' that a 'wrapper is 'bad'. You cant tell them they're getting it wrong, that everything works that way, that that's how software works in the first place; they're not interested in listening. They're invested in complaining, and that's all they do.

[J4R1O]

Well, one can check the CW forums...seems a good barometer I'd think. Seen a few SUEs there...

That forum is really something... something beyond something...

Take a look at the reply that poor guy gets:

http://forum.cakewalk.com/X3-Tape-Emula ... 00350.aspx