Why does Cakewalk stuff use a VST 'wrapper' for VST effects and VSTi's ?
Are there any advantages to this approach ( I can't think of any) ?
I noted that the wrapper doesn't run as a background task and therefore I guess it doesn't use any processing cycles.
FL Studio, as an example, handles VST and DX without an external wrapper program. My understanding is that the wrapper is fxpansions work.
Cakewalk VST wrapper ?
-
- Beware the Quoth
- 35476 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
luxgud quoth Why does Cakewalk stuff use a VST 'wrapper' for VST effects and VSTi's ?
Same reason other stuff does; because the internal workings of their software is not based around the VST standard. It just so happens that their wrapper is a separate program, rather than a part of the host.
Are there any advantages to this approach ( I can't think of any) ?
Yes, a couple.
The wrapper is a single program, so it can be updated without requiring changes to the host, which increases stability/maintainability, and frees it from the hosts update cycle.
It means that there's plugin consistency across all CW hosts.
It also separates the scanning-for-plugins stage from the host, decreasing startup times.
By separating the scan from the host, it stops a new 'rogue' plugin from breaking your host until you're ready to 'enable' it by running the adaptor.
It also means (as a side effect) you have more control over customisation of the settings of the plugins.
I cant think of any major disadvantages of doing it this way, can you?
noted that the wrapper doesn't run as a background task and therefore I guess it doesn't use any processing cycles.
No, its basically a simple passthrough of data with an ansolutely minimal overhead.
FL Studio, as an example, handles VST and DX without an external wrapper program.
No, it uses an internal one.
My understanding is that the wrapper is fxpansions work.
Cakewalk's was. FL's never has been.
Same reason other stuff does; because the internal workings of their software is not based around the VST standard. It just so happens that their wrapper is a separate program, rather than a part of the host.
Are there any advantages to this approach ( I can't think of any) ?
Yes, a couple.
The wrapper is a single program, so it can be updated without requiring changes to the host, which increases stability/maintainability, and frees it from the hosts update cycle.
It means that there's plugin consistency across all CW hosts.
It also separates the scanning-for-plugins stage from the host, decreasing startup times.
By separating the scan from the host, it stops a new 'rogue' plugin from breaking your host until you're ready to 'enable' it by running the adaptor.
It also means (as a side effect) you have more control over customisation of the settings of the plugins.
I cant think of any major disadvantages of doing it this way, can you?
noted that the wrapper doesn't run as a background task and therefore I guess it doesn't use any processing cycles.
No, its basically a simple passthrough of data with an ansolutely minimal overhead.
FL Studio, as an example, handles VST and DX without an external wrapper program.
No, it uses an internal one.
My understanding is that the wrapper is fxpansions work.
Cakewalk's was. FL's never has been.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
-
- KVRAF
- 12235 posts since 18 Aug, 2003
W'rabbyt quoth I cant think of any major disadvantages of doing it this way, can you?
I can think of two, both related to the conversion to DX. The first being you lose your directory hierarchy by moving VSTs over to DX. Not so much an issue I gather if you use Sonar (your Subsonar helps here doesn't it?) but a pain with other DX hosts. The other is if you have another host that runs both VST and DX, you end up with a doubled list of plugins. Major pain when trying to find something.
It's a bit misleading to say that other hosts use an internal wrapper. The Cakewalk wrapper does something a little different than just accessing VST plugins, it actually registers them as DX plugins. Not a major difference maybe, but still a difference.
As for updating, it's sort of a glass half full/half empty kind of point. While one party could suggest it is better with a wrapper because you no longer need to force the host's update cycle to match VST hosting bugfixess, another party could just as easily say it's worse because now I have two separate applications to maintain, and another layer to deal with when trying to troubleshoot.
I can think of two, both related to the conversion to DX. The first being you lose your directory hierarchy by moving VSTs over to DX. Not so much an issue I gather if you use Sonar (your Subsonar helps here doesn't it?) but a pain with other DX hosts. The other is if you have another host that runs both VST and DX, you end up with a doubled list of plugins. Major pain when trying to find something.
It's a bit misleading to say that other hosts use an internal wrapper. The Cakewalk wrapper does something a little different than just accessing VST plugins, it actually registers them as DX plugins. Not a major difference maybe, but still a difference.
As for updating, it's sort of a glass half full/half empty kind of point. While one party could suggest it is better with a wrapper because you no longer need to force the host's update cycle to match VST hosting bugfixess, another party could just as easily say it's worse because now I have two separate applications to maintain, and another layer to deal with when trying to troubleshoot.