Sonar 8 not VST3 compatible?

Anyone found a word about VST3 ??

SONAR doesn't support VST3. We haven't seen any compelling reason to support VST3 since VST 2 is capable of doing pretty much all that VST3 can do. VST3 is largely a somewhat improved API to talk to VST's with very little gain to the end user or host developer. It would be way too much work for us to support with no known gains.

I'm not even sure of any VSTs that are VST3.

We haven't seen any compelling reason to support VST3 since VST 2 is capable of doing pretty much all that VST3 can do

Hmm... vst 3 helps saving cpu & get a great classification function (called mediabay in cubase) : no more vsti's Gui, all the sounds from all the synths in a single window, classified in strings, bass, piano, etc...
Maybe a little steinberg/yamaha vs cakewalk/roland war under that... and most of the plugs to come will be vst 3. So come on, cakewalk : vst 3 in sonar 9. (stop bundeling and bring reall new functions in new software versions)

ORIGINAL: Logicology

I'm not even sure of any VSTs that are VST3.

The Virsyn effects plugins are; Harry Gohs also did the new synths in Cubase 4 (which also are, obviously).

http://www.virsyn.de/en/E_Home/e_home.html

The one thing I can see being useful in the VST3 spec is dynamic ins as well as outs for plugins. With that, you could have (for example) a surround plugin that has four inputs instead of the normal stereo in...

As for MediaBay, there's other alternatives. NI's .ksd format is one, Arturia uses an attribute system for Analog Factory, and Virsyn's latest couple synths (miniTERA and POSEIDON) also do.

ew

There is really no reason why VST3 will save CPU. The exact same techniques used by VST 3 can be adapted to any VST plugin. The Media bay has absolutely nothing to do with VST per se its an application feature.
I have reviewed the VST3 spec and its primarily just a new API.

The exact same thing is available in VST2. How do you think sidechaining is done?

ORIGINAL: ew
The one thing I can see being useful in the VST3 spec is dynamic ins as well as outs for plugins. With that, you could have (for example) a surround plugin that has four inputs instead of the normal stereo in...

ORIGINAL: Noel Borthwick [Cakewalk]

The exact same thing is available in VST2. How do you think sidechaining is done?

hmm... so why does it took ages to get side chaining in the app, and why a plug inserted in the plug rack (on an audio clip) still eats cpu when the clip is not playing ? This is a non-sense. Why sonar and cubase are not dealing with plugs like samplitude do ? I mean i really do not care about vst 3, but i care about cpu... So please, vst 3 or not, shut up the plugs when they're not working... (and mediabay is a really cool feature..)

Implementing sidechaining had only a very small amount to do with plugin capabilities. For example sidechainig has been possible with DX plugins since 1997. The mpre complex part has to do with the host side implementation.
Sidechaining has been there since SONAR 7. It was pretty much widely requested roughly around the time of SONAR 6 and we implemented it in the next version. Feature requests are implemented based on resource availability and demand ratio.

Regarding CPU, the reason why VST plugins consume CPU when bypassed is because they are still enabled. They are kept enabled to avoid gaps or discontinuities while unbypassing. All VST 3 has is a flag to tell the plugin you are streaming zeros, something we have done with DirectX plugins since the beginning of time through a custom interface in our DXi SDK. There is nothing technically stopping VST vendors from implementing the VST3 capability as a custom opcode. Once that is done widely we will support it. We cannot control what plugin vendors do.

ORIGINAL: budweiser

ORIGINAL: Noel Borthwick [Cakewalk]

The exact same thing is available in VST2. How do you think sidechaining is done?

hmm... so why does it took ages to get side chaining in the app, and why a plug inserted in the plug rack (on an audio clip) still eats cpu when the clip is not playing ? This is a non-sense. Why sonar and cubase are not dealing with plugs like samplitude do ? I mean i really do not care about vst 3, but i care about cpu... So please, vst 3 or not, shut up the plugs when they're not working... (and mediabay is a really cool feature..)

EDIT: NM about the CPU, I was going to mention freezing but apparently Noel is saying bypassed plugins still use the CPU.

Also there are a couple free alternative to mediabay, such as this one: http://www.wusik.com/w/wvm.html

D.

Because potential buyers might be ignorant to the position that Cakewalk has taken "That there is no real benefit to supporting VST3", shouldn't there be a warning label on the box and marketing releases? This seems like a political mistake. Steinberg has to be giddy about this.

Yeah, I was under the impression from Steinberg that VST3 were capable of using CPU only where clips are located in a track. I thought this was brilliant. Noel is this not the case? Are you saying VST2 and DXI are capable of this feature. If that is the case, can we expect to see Sonar plugs in the future written with this functionality. It seems like a very logical step, a giant leep foward. Plus, it seems like Stienberg is marketing VST3 as the only plug cabable of this functionality. That doesn't seem right to let them get away with that misconception.

ORIGINAL: WDI
Are you saying VST2 and DXI are capable of this feature. If that is the case, can we expect to see Sonar plugs in the future written with this functionality. It seems like a very logical step, a giant leep foward. Plus, it seems like Stienberg is marketing VST3 as the only plug cabable of this functionality. That doesn't seem right to let them get away with that misconception.

Check out the Blue Cat Audio VST plugins that already have this feature.

http://www.bluecataudio.com/Products/Product_Dynamics/

Blue Cat Audio Standards:
Native DSP code for optimal performance.
Skinnable user interface.
DirectX and VST plug-in formats support.
Smooth Update: silent (zipper-free) parameters update.
Full automation support (all parameters can be automated, with smooth and continuous update)
No CPU load on idle: when the plugin is fed with silence, the processing smoothly shuts down, to optimize the CPU usage of your Digital Audio Workstation.
Real time MIDI control with advanced settings (MIDI channel and CC numbers, with complete response curve control) and MIDI learn.
Any sample rate supported.

This was from Blue Cat Audio website

No CPU load on idle: when the plugin is fed with silence, the processing smoothly shuts down, to optimize the CPU usage of your Digital Audio Workstation.

Wow, I can't believe this isn't just a standard. It makes a lot of sense.


Edit:

I didn't refresh before you edited last syrath.

Have you used these plugs before syrath. They look like a good company.

They make pretty good plugins as well.

ORIGINAL: budweiser

...(stop bundeling and bring reall new functions in new software versions)

Amen to that...

Until at least 75% of all PlugIn manufacturers are producing thier plugs in VST3. I see no need for Cakewalk to support it..
It would be silly for PlugIn manufacturers too to solely do VST3 plugs too, and drop VST2.

Before people jump on the bandwagon to disparage Sonar for not having VST 3 support, you should all do some reading. This topic has been discussed to death in other forums, and other developers have stated the same reasons as Noel. While there are a few plugs that support VST3, Cubase 4 is still the only host that actually uses the VST3 standard, and they did this at the cost of having to cut DX plugs out of their program. That's not a price I'm willing to pay. It also didn't help that Steinberg kept the other companies in the dark about VST3 so they could get a 'perceived' market advantage for over a year. Not only did they drag their feet in letting people come to grips with VST 3, but they refused to work with a new 'universal standard' for plugins that Ron Kuper had worked on. The name of that standard now slips my mind, but from what I understood, Cubase was unwilling to work with everyone, and the project was killed.

One of the big problems with VST 3 is that a lot of the VST 2.3 plugs STILL do not work correctly in VST 3 and would have to be updated to be compatible. Another price that I'm not willing to pay.

This thread has a lot of info on what devs really think about it, and just how much work it would be to do with a really small amount of gain:

http://www.kvraudio.com/forum/viewtopic.php?t=206135&postdays=0&postorder=asc&start=0

I'm not for or against VST3. DXI or VST is fine by me. A standard would be helpful for everyone I'm sure.

I know little about VST3, but I was under the impression that the new design would free up a hosts CPU and that sounded great. I saw Noel chime in and set some things straight. But I'm just wondering, why isn't this feature being implemented by Sonar. It sounds like it's not the host that needs this functionality but it needs to be designed into the plugs. I'm just wondering, if Cakewalk is designing a lot of the plugs that come in Sonar, why aren't they taking advantage of this feature? It just seems logical to free up the host CPU when nothing needs processing. I'm really glad to hear this is not a feature solely provided by the VST3 format and that we Sonarians could also benefit from this feature without the need for VST3 support.

WDI, it's a relatively new standard I guess is the answer. In this months Computer Music, someone did ask about a certain plugin, being VST 2 and how it to use it with VST 3, and it came down to the way side chaining is dealt with.. (in their case they were using cubase 4).. although there was still a way around using the plugin as a side chain, using a different approach. Which worked just as well.

If you think about the vast amount of plugin's free or commercial that are VST 2 , it's a LOT.. bit like a repeat of why companies are taking their time with 64 bit drivers etc.

Still I guess it keeps programmers busy (as if they aren't already enough as it is)

if it's one company involved it's easy, but think how many companies products support/use vst in their DAW/host programs , then there is the thing with the VST-i / fx makers themselves.

it probably runs into 1000's of individual developers.

Another Dev's view:

http://www.analogindustries.com/blog/entry.jsp?msgid=1208903114014

This is the KVR thread I was originally looking for where the devs openly discuss VST3.

http://www.kvraudio.com/forum/viewtopic.php?p=2907056

VST3 really brings nothing to the table of any importance to us. We'd much rather work on engineering our application rather than adopting another standard that doesn't bring any substantial gains. The VST3 spec breaks a fundamental premise that we believe in and that is backwards compatibility. To support VST 3 really means that both plugin vendors and hosts have to completely write new components - a huge development and testing exercise.

I have spoken to other DAW vendors and VST developers who unanimously agree that there is no gain to VST3.
In fact a few plugin vendors have proposed alternate VST2 compatible specifications that far exceed the VST3 specification.

Outside of Steinberg's own are there any VST 3 plugs around?

Ok, here's my question(s). The one thing that impressed me with VST3 was that it sounded like it freed up the host CPU when processing was not needed. However, it sounds like VST3 is not needed for this to be the case. Can Sonar currently take advantage of this feature, when no processing needs to be done the host CPU is freed from the burdon of the plugin in the track/bus effects bin? If so, what make this happen? Is it the plugin? Currently, I think all my plugs continuously process whether they need to or not. And secondly, why don't they? Is this a new feature available that plug venders have not taken advantage of? If I run plugs lets say by Blue Cat Audio who claim that "No CPU load on idle: when the plugin is fed with silence, the processing smoothly shuts down, to optimize the CPU usage of your Digital Audio Workstation" will my CPU be free from processing the plug during places where there is no clip on the track? And also, does this run smoothly? To me this feature seems very significant. I just always accepted the fact that a plug always effects the CPU whether processing is necessary or not.

ORIGINAL: WDI

Ok, here's my question(s). The one thing that impressed me with VST3 was that it sounded like it freed up the host CPU when processing was not needed. However, it sounds like VST3 is not needed for this to be the case. Can Sonar currently take advantage of this feature, when no processing needs to be done the host CPU is freed from the burdon of the plugin in the track/bus effects bin? If so, what make this happen? Is it the plugin? Currently, I think all my plugs continuously process whether they need to or not. And secondly, why don't they? Is this a new feature available that plug venders have not taken advantage of? If I run plugs lets say by Blue Cat Audio who claim that "No CPU load on idle: when the plugin is fed with silence, the processing smoothly shuts down, to optimize the CPU usage of your Digital Audio Workstation" will my CPU be free from processing the plug during places where there is no clip on the track? And also, does this run smoothly? To me this feature seems very significant. I just always accepted the fact that a plug always effects the CPU whether processing is necessary or not.

I only works for simple plugs. If you have a plug that syncs to host tempo, and you shut it off, it won't be synced when the plug starts back up. If you read the links I provided, there are other issues with the process also. While it sounds like a good idea, the tech simply isn't there yet. Could you imagine the amount of glitching caused by several plugs starting and stopping at the same time? I think the best bet right now is to render audio to free cpu, and archive the original track to take the load off. If you need to tweak something, delete the audio track, tweak your now unarchived original track, and render again. That's what I end up doing.

ORIGINAL: budweiser
most of the plugs to come will be vst 3

Where did you get this information, off of Steinberg's web site?
Maybe a some point in the future, but at the present none of the devs I know are in any hurry to support it.
If it means loosing compatibility with DX (or my older VST plug-ins ) then AFAIC VST3 support can remain a Cubase exclusive.

Steinberg has to be giddy about this.

Yeah, a lack of oxygen will do that.


...Steven

Original: Resonant Order

While it sounds like a good idea, the tech simply isn't there yet. Could you imagine the amount of glitching caused by several plugs starting and stopping at the same time?

Yeah, that's kinda what I was wondering about. I did start to read that thread you posted. It's like at leat 17 pages so I got side tracked. I'm good at that, getting side tracked.

I wish they would make a standard for plugs to be able to take advantage of this feature smoothly. It would be very beneficial from my view point. Very convenient.

That link to the Audio Damage blog pretty much says it all: "none of our current products would benefit directly from VST3's additions". Exactly what Noel said.

VST3 seems to be driven by Steinberg marketing rather than to answer any technical need. They could have borrowed the tactic from Microsoft.

Q: How many Microsoft engineers does it take to change a lightbulb?

A: None. They just change the standard to "dark".

Yep.. Its just Steinberg trying to win back thier market share that they have lost in the past few years that Sonar, Logic and Repear have taken..

ORIGINAL: John

Outside of Steinberg's own are there any VST 3 plugs around?

See my post above...

ew

VST3 is what future plug-ins will likely be authored as it is a cleaner API with much better support for side chaining as well as the ability to NOT process freeing up CPU as well as add and remove channels on the fly. It is NOT an update that can simply be ignored. I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins. Cakelwalk needs to be ahead of the curve not behind it. This is up there with Waves not offering 64 bit support "until they see a demand". I have to run Sonar in 32 bit because of their lack of support. Just as Waves foot dragging on 64 bit makes me less inclined to buy their plug ins, this news makes me think less of Cakewalk and their commitment to staying at least up with the current state of music technology.
So my question for those at Cakewalk is WHEN? will you catch up to the current VST platform?

ORIGINAL: plainfaced

Yep.. Its just Steinberg trying to win back thier market share that they have lost in the past few years that Sonar, Logic and Repear have taken..

It's good to see a world authority on market shares dropping their wisdom on these boards. Why don't you delete all your vst plug-ins after all Virtual Studio Technology was invented by shhhh you know who.

ORIGINAL: lacyth

VST3 is what future plug-ins will likely be authored as it is a cleaner API with much better support for side chaining as well as the ability to NOT process freeing up CPU as well as add and remove channels on the fly. It is NOT an update that can simply be ignored. I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins. Cakelwalk needs to be ahead of the curve not behind it. This is up there with Waves not offering 64 bit support "until they see a demand". I have to run Sonar in 32 bit because of their lack of support. Just as Waves foot dragging on 64 bit makes me less inclined to buy their plug ins, this news makes me think less of Cakewalk and their commitment to staying at least up with the current state of music technology.
So my question for those at Cakewalk is WHEN? will you catch up to the current VST platform?

Please read the former posts in thread...

ORIGINAL: lacyth

So my question for those at Cakewalk is WHEN? will you catch up to the current VST platform?

Answered by Noel several posts ago.

ORIGINAL: bitflipper
That link to the Audio Damage blog pretty much says it all: "none of our current products would benefit directly from VST3's additions". Exactly what Noel said.

Aleksey Vaneev (of Voxengo) mentioned much the same. (bold emphasis mine)

ORIGINAL: http://www.kvraudio.com/forum/viewtopic.php?p=3517709
With Voxengo situation is same - no VST3 support in a foreseeable future.

I also have not received many VST3 support requests from the users - maybe less than 5, and mainly with the desire to have a seamless side-chain support, which is a bit tricky in Cubase for VST2.4 plug-ins.

I can start working on VST3 only when these vendors start to support it: Cakewalk (Sonar), Ableton (Live), Sony (Vegas, SoundForge), Cockos (Reaper), Magix (Samplitude). Without that the benefits of supporting VST3 are marginal.

ORIGINAL: lacyth

...I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins.

What VST3 plugins are there that you need and aren't able to use right now?

ORIGINAL: lacyth
I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins.

You buy a product (SONAR, Cubase, Renault Megane, hedge trimmer, microwave oven, etc.) on the basis of what it does now, not what it 'might' or 'should' do at a later date. Otherwise you've made an investment, not a purchase.

I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins.

"Absolutely astonishing and unacceptable", huh. Wow. I didn't realize that all the must have plug-ins only came in VST3 format, leaving you "stranded" using an outdated, unsupported format. You know, the one that the other 99% of available plug-ins use.

So my question for those at Cakewalk is WHEN? will you catch up to the current VST platform?

My guess would be when other non-SB hosts like Logic, DP, Reaper, Samp, etc all support it as well.

VST3 is what future plug-ins will likely be authored as it is a cleaner API with much better support for side chaining as well as the ability to NOT process freeing up CPU as well as add and remove channels on the fly. It is NOT an update that can simply be ignored. I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins.

FWIW, The only VST3 compliant plugins you can't use right now are:
1. The VST Motif Editor (You can still use the Studio Manager version of the Editor or John Melas' Editor)
2. Cubase 5's included VST plugins (which you can't use in Sonar anyway)
3. The Virsin plugins EW mentioned earlier

Noel explained why Cakewalk isn't supporting VST3 (at least for now)...
VST3 isn't adding any significant new capabilities beyond what's already been possible.
Thus, there's just not a great impetus to support VST3 at this time.
Most developers feel the same way... so it's not just a Cakewalk/Sonar decision or train of thought.
To my knowledge, Cubase 5 is the only (major) host software that supports VST3.

When Jim speaks, everybody should listen!

Jim knows his stuff...Do NOT doubt his knowledge...(and I'm not being facetious or a suck-up)...

Fabfilter is releasing VST3 version of its plugins, but, as well said previously, they are still a very narrow niche by now, and they offer so little (almost nothing) more than you can already achieve with VST2.4.

So why should an host developer bother with several hours coding to support something what is, as a matter of fact, currently a one brand thing only?

- Mario

ORIGINAL: Noel Borthwick [Cakewalk]

I have spoken to other DAW vendors and VST developers who unanimously agree that there is no gain to VST3.
In fact a few plugin vendors have proposed alternate VST2 compatible specifications that far exceed the VST3 specification.

Sounds like Steinberg have jumped the gun and not made the best of VST3 . . . could this become a VHS v BetaMax / HD-DVD v Blue-Ray situation?

Since there were various posts talking about sidechaining in VST 3, here is a white paper I wrote on how sidechaining is done using plain old VST 2.4. This is how its implemented in SONAR and how several other vendors do it today.
VST 2.4 Side-chaining in SONAR

Nicely done, Noel. Thanks for sharing that.

Hi all,

This is actually a programmer issue, not a user issue.

Some time ago, I also downloaded the VST3 SDK and looked at it. I agree with Noel that this is pretty much just a different API, but I thought it looked more well-organized (at first glance anyway --- VST2 is pretty bad in that respect). The question I asked myself, and I'm sure a lot of "real" VST/VSTi developers have: Which API should I use? Because of the presence of SONAR and other non-Steinberg DAW's, the answer is pretty obvious: VST2.

It's somewhat silly for a professional programmer to write a VST or VSTi for which there would be only one family of hosts from a single vendor. My initial and limited first impression was that the VST3 API would probably be easier to learn and use, but that adoption would be quite a ways off yet. Many folks have invested a LOT of time learning the VST2 API, and they are not going to just jump into a new one with very few others doing so at the same time. VST3 is not just a "new version" of something like a new version of SONAR. It's more like a different language, related yes, but taking a lot of time to learn.

Regards,
Dave Clark

Let's revise this discussion.

What is the current stand by Cakewalk about VST3?

CW's stand is it is unnecessary. It offers nothing that VST 2.4 doesn't already offer. 

So the enhanced functionality of plugs who adopt a VST3 standard, for new features on existing plugins, may leave SONAR out of the market when a host is decided based on the plugin(s) functionality.

too bad...

I wonder if that user survey is still open for feedback.

I'd be really surprised if Cakewalk adopted VST3 support this year (or anytime soon).
I just don't see the payoff, in terms of sales gained or lost, vs the cost of implementing. 
IMHO there are so many other areas where the manpower could be better spent.

Edit: fixed typo - somehow accidentally created link, instead of deleting a line.

Guitarmech111


So the enhanced functionality of plugs who adopt a VST3 standard, for new features on existing plugins, may leave SONAR out of the market when a host is decided based on the plugin(s) functionality.

too bad...

I wonder if that user survey is still open for feedback.

What "enhanced functionality"?

The fact that Yamaha wrote its Motif editor specifically for VST3 was (likely) entirely a business decision, calculated to produce something in the marketplace that couldn't be run on other hosts.  It's highly unlikely that all the functionality in that editor could not be implemented in VST2.x.

So far, I'm not seeing plug vendors (other than Yamaberg) producing VST3 only versions of their plugs.  (Have I missed some?)

Guitarmech111


So the enhanced functionality of plugs who adopt a VST3 standard, for new features on existing plugins, may leave SONAR out of the market when a host is decided based on the plugin(s) functionality.

too bad...

I wonder if that user survey is still open for feedback.

I take it that your question was rhetorical. Clearly you dismissed my answer. I got that answer from Noel BTW.

I can see CW offering support when it becomes a standard as in many plugins are in that format. I don't see CW supporting it otherwise.

There is no compelling reason at this point to support it.

Noel Borthwick [Cakewalk
]

There is really no reason why VST3 will save CPU. The exact same techniques used by VST 3 can be adapted to any VST plugin. The Media bay has absolutely nothing to do with VST per se its an application feature.
I have reviewed the VST3 spec and its primarily just a new API.

Hey Noel, nice to speak to someone from Cakewalk, "I'm not Worthy".  look some of these messages are a little on the silly side aren't they.  I see no reason for VST 3, yet either.  Has anybody really thought about the most important thing and that is the music, its all about the music. 
"I HAVE NEVER HAD A PROBLEM WITH THIS SOFTWARE" and i have run some crazy setups that included Creamware audio cards in XTC mode which was not even supported in SONAR.
Unlike Logic and don't get me started about Pro-Tools 8 and Vista, it took me a whole month of going through everything to make it work on my woman's computer.
Come on people this software is the bomb, it does so many things now that were not even dreams when The Beatles were in the studio.
When i have finished my masters thesis, which is to recreate two Beatles classics (Strawberry Fields and Because) in Sonar.  I hope Sonar aficionados understand and be a little kinder to the people at Sonar.  As I keep saying it is impossible to do what i am attempting in any other DAW and i will stake my degrees and career on that.
 
Viva La Revolution
Sonar Forever, Pro Tools Never
Ben B.CT (Bachelor Of Creative Technology)

lacyth


. I find it absolutely astonishing and unacceptable that as I Sonar 8 user I am stranded at VST2 and can't use newly developed plug-ins. So my question for those at Cakewalk is WHEN? will you catch up to the current VST platform?

I find it absolutely astonishing and unacceptable that you chose to ignore the previous 30 posts in this thread detailing why adopting the VST3 standard is not only un-necessary but totally impractical at this time.
 
But I suppose it gets your post count up.

dantarbill

Guitarmech111


So the enhanced functionality of plugs who adopt a VST3 standard, for new features on existing plugins, may leave SONAR out of the market when a host is decided based on the plugin(s) functionality.

too bad...

I wonder if that user survey is still open for feedback.

What "enhanced functionality"?

The fact that Yamaha wrote its Motif editor specifically for VST3 was (likely) entirely a business decision, calculated to produce something in the marketplace that couldn't be run on other hosts.  It's highly unlikely that all the functionality in that editor could not be implemented in VST2.x.

So far, I'm not seeing plug vendors (other than Yamaberg) producing VST3 only versions of their plugs.  (Have I missed some?)

If I told you, I would have to shoot you.  ;)

Noel Borthwick [Cakewalk
]

SONAR doesn't support VST3. We haven't seen any compelling reason to support VST3 since VST 2 is capable of doing pretty much all that VST3 can do. VST3 is largely a somewhat improved API to talk to VST's with very little gain to the end user or host developer. It would be way too much work for us to support with no known gains.

It doesn't matter! Cakewalk and SONAR should still support VST3.

SONAR should always be pioneer and support all kinds of new technology when it comes along. It doesn't matter if still few use it and from my own experience, more and more 3part manufactures adds VST3 support now. That's why we all use SONAR instead of any other DAW:s, because fast adoption of new technology. First on adding x64bit support, multi core support, best audio quality..etc


Be advice: Don't forget that many said the exactly the same in the beginning about "no compelling reason" to add x64bit support either. Now we all use it! 


Best Regards
Freddie

Why should Cakewalk support a complete rewrite of its plug-in interface when there are, from practically every account, "no known gains" from doing so? Just so they can put a sticker on the box saying "New! Improved! Now with Miracle Ingredient VST3! Makes your car's audio engine run 20-40% better"? That's not leadership, that's me-too-ism.

VST3 is at present little more than a Steinberg marketing gimmick IMO. It offers practically nothing to the user, and any benefits to programmers are gained only at the cost of huge upheaval -- at present, probably far more must be invested in the so-called "upgrade" than will be returned. At least that's the business and technical decision Cakewalk have made regarding VST3, and I agree with it.

Maybe that jbridge fella should make a VST3 => VST2.4 adapter... then he can have all the fun fixing all of the new VST3 ports of old VST2 plugs from developers who just barely got their VST2 plugs working in 17 different hosts...

Oh, never mind, I forgot... there aren't any VST3 ports of old VST2 plugs...

Well, 3.1 apparently includes a wrapper. Still doesn't make things more compelling from a host standpoint, but it's a move in the right direction.

Whether or not Cakewalk sees any advantage/improvement in VST3 over VST2 is a moot point. Cakewalk doesn't control the VST process - Steinberg does. And the latest version is 3.0 - so Cakewalk is behind. 

I recently got the Waves Vocal Rider plugin - it is VST3 and the sidechain feature doesn't work in Sonar - it does work in Cubase, which supports the latest version of the VST standard.

I agree with what someone said earlier - one less bundled synth - one more supported standard. Sticking your head in the ground isn't going to make VST3 go away.


Wow I'm actually agreeing with Freddie 

Maybe, maybe not. I remember an audio salesman telling me something along the lines of "Sticking your head in the ground isn't going to make Quadraphonic Eight-Track Surround Sound* go away." :-}

Which isn't an attack against you, just saying the adoption of VST3 isn't an inevitable process. Plenty of proposed "improvements" have fallen flat. The marketplace will decide, of course, not us -- except as each of us buys or doesn't buy. To me, VST3 is a non-issue. I want sound, flexibility, comfort of use, and power. Interface standard? Not concerned unless it makes a real-world difference to me.
__________________
* [edit] Yes, I was wearing bell-bottoms and a floral print blouse at the time. =O.o= Guilty. We all dressed that way back then. Some of us.