Vintage Channel VC64 not 64-bit?

Is Vintage Channel (VC-64) not a 64-bit plug-in?  When I add it in 64-bit Sonar (8.5), it opens in BitBridge!
 
I verified that it's loading from the 64-bit vst folder (not from "Program Files (x86)").
 
Can anybody confirm this, or otherwise tell me how to load the 64-bit VC64?
 
Cheers!
 
P.S. If it's only 32-bit, what's with the name VC64?  Does it stand for 64 of something else?

Can we get a translator?
Are you saying VC-64 is a 64-bit plug-in, and should NOT be using BitBridge?

Seth Perlstein [Cakewalk
]

VC-64 is a 32-bit plugin so it must use Bit-Bridge.

I know the company that made VC64 is no longer in biz, but are there any plans to update the plugin or make it 64bit natively?
 
And, why call it VC64? lol
 
 

What!!! hey thats misleading, i love that plugin.  Hmm why call somthing vc64 when it is not 64 bit.  The overtones suggest that it is 64 bit,  for the first time in a while i feel a little duped.

Viva la Revolution
Ben B.C.T (Bachelor of Creative Technology)
Sonar Forever, Pro Tools Never
http://www.myspace.com/audiomystics

It processes at an internal data stream of 64 bits. Ozone when it was only in 32 bits did the same thing. A plugin that is native 64 bits does not in and of itself mean it is also processing at 64 bits.

What!!! hey thats misleading, i love that plugin.  Hmm why call something vc 64 when it is not 64 bit.  The overtones suggest that it is 64 bit, 

There 2 different completely things. The VC 64 uses 64bit processing. You can use 64bit processing in a 32bit windows. Why,? because one has nothing to do with the other. If you know that, its not misleading 

John


It processes at an internal data stream of 64 bits. Ozone when it was only in 32 bits did the same thing. A plugin that is native 64 bits does not in and of itself mean it is also processing at 64 bits.

But they didn't name it "Ozone 64" to mislead -- and they clearly said it was 64 bit "processing" in their marketing.
 
I think it's unfortunate CW went with "VC 64" in this case.   Though I do like the plugin a lot.
 

John


Well CW also called the 32 bit version of the LP-64 EQ and Multiband LP 64s. Though neither are 64 bit plugins on a 32 bit OS.

It does appear that VC-64 is the only one out of all the "xx-64" named plugins that does not run natively in 64-bit Sonar.

How right you are CJ, ol pal.

John


Well CW also called the 32 bit version of the LP-64 EQ and Multiband LP 64s. Though neither are 64 bit plugins on a 32 bit OS.

Its not what its native bit depth is but that it is processing at 64 bits.

This would apply to all so called 64 x plugins on a 32 bit OS.

That's another example of the marketing ploys.   I thought, originally, the LP 64's *were* 64bit.  I later discovered they are not (which is ok considering I'm on 32bit OS).
 

VC64 was released with Sonar 6, if I recall, which was released in September 2006 (please correct if I'm misremembering). At the time, hardly anyone was using an x64 OS. While Sonar x64 did exist at the time (as of Sonar 5), it only ran on Win XP x64 edition and Windows Server 2003 x64, if I recall. But virtually no one used those OSes on DAWs (except for a few daring pioneers, who ended up having almost universal, aggravating plugin and/or driver experiences). 99.99% of users were still on good ol' fashioned XP 32-bit.

On top of that, Vista wasn't officially released until January 2007, I believe, including the x64 version.

So in all fairness, the REAL x64 era began with Vista x64 in 2007, AFTER Sonar 6 and VC64 had already been released. Before then x64 was the domain of the few, the proud, the crazy, and/or bleeding edge folks, not to mention the marketing folks at Cakewalk who took every opportunity to show how far ahead they were compared to their competition at the time (in that arena).

Also, Cakewalk had only recently introduced the 64-bit mixing engine (which they also touted extensively) on the 32-bit version of Sonar, so it was clear that there were separate issues when it came to 64-bit. They made it very clear, right from the beginning, that there was 64-bit audio processing and x64 instruction set, and the two were distinct. Endless threads in this forum covered these issues.

64-bit audio processing (as in, the audio engine and bit depth), was pretty new in general, and just about everyone touted that in their marketing materials if they had it.

So at the time, you can hardly fault Cakewalk for calling VC 64 what they did... the 64 at the time was very clearly in reference to the 64 bit audio processing, NOT the x64 instruction set.

However, it is definitely unfortunate what happened with Kjaerhus, and one can only hope that Cakewalk has been able to get a hold of the source code and update VC64 to x64 native instruction set so that it no longer needs to use BitBridge. There is no way Cakewalk could have predicted that Kjaerhus would go out of business, etc., so if anything, the only thing we can fault Cakewalk with here is that they named the plugin poorly, they relied on 3rd-party plugin developers perhaps once too often, and/or they didn't predict the future well enough. :)

Having said that, VC64 does work well with BitBridge, and it is almost inevitable that you will need to run some plugins in BitBridge until everyone updates their plugins. Fortunately, that's happening more and more each passing week. Cakewalk has spent an enormous amount of resources (I count three major upgrades to BitBridge, and several minor improvements over the years) to make it perform very well.

But I do agree that to a newcomer to Sonar, now that we're fully into the x64 world, the VC64 plugin name is indeed misleading... but in context I hope it's clear that Cakewalk wasn't trying to dupe anyone with that name. It's just how "life" and "business" work out sometimes. No one is really to blame (we still don't know what really happened with Kjaerhus -- who knows, perhaps there was some family tragedy or something terrible happened), and in the end, you can still use VC64, and it's still a very decent-sounding plugin.

eratu

ba_midi

John


Well CW also called the 32 bit version of the LP-64 EQ and Multiband LP 64s. Though neither are 64 bit plugins on a 32 bit OS.

Its not what its native bit depth is but that it is processing at 64 bits.

This would apply to all so called 64 x plugins on a 32 bit OS.

That's another example of the marketing ploys.   I thought, originally, the LP 64's *were* 64bit.  I later discovered they are not (which is ok considering I'm on 32bit OS).

This is a great point, and since those plugins were introduced later on, I agree that their names are unfortunate. My guess is they were still on the VC64 marketing/naming convention path, and didn't think at the time that "64" would really come to mean x64 instruction set, as opposed to 64-bit audio processing. So I think you've got a solid point. They probably shouldn't have named LP64 with "64" in there. Hopefully that situation will be remedied with Sonar 9, however, since by all accounts, Cakewalk controls the source code to those newer plugins.

Well, I've become a huge cynic when it comes to marketing in general.  I think it was probably 'intentional' to name them with "64" in the nam.  But that's just my take on it.
 

eratu

ba_midi

Well, I've become a huge cynic when it comes to marketing in general.  I think it was probably 'intentional' to name them with "64" in the nam.  But that's just my take on it.

You might be right, and it's easy to be cynical when so much of marketing is bullsh*t, from any company. Either way, I don't think the naming of these plugins was truly misleading per se... on a very technical level, they do process audio internally at 64-bits. And at the time they were released, it can be reasonably argued that "64-bit" wasn't *necessarily* indicative of x64 instruction set. So they can get away with it... this time. But how malicious is that, really? Not much in my book. There are plenty of other marketing foibles I bet you and I can agree on that we'd shake a stick at first before the poor naming of these plugins. :) But that's for another day and another thread.

Yeah, I wouldn't frame it as "malicious" either.  Just a bit misleading.   And x64 has been a major push for CW for a long time now, so that's why I felt cynical about that naming convention.
 
But, it's not a big deal really.
 

It's not bad marketing imo; this time I agree with CJ - snow coming!

There are 64 bits operating system and 64 bit audio streams; they aren't the same thing.

VC64, and LP64 and so, handle 64 bit streams, so their name.

They don't run natively in 64 bit operating systems, need bit bridge for that - they are built for 32 bit operating systems.

That's it :)

- Mario

Funny I at no time thought a plugin named with 64 in its name meant anything about it being a native 64 bit plugin. Further I'm a bit confused about this as what advantage is there going to be if it is a 64 bit native plugin? We are not talking about a sampler or a VSTi rather plugins that are meant to process the audio with as little distortion as possible. It doesn't matter if its 32 bit native or 64 bit native. Except if you want to use it in a 32 bit environment.

What I want to know is are there any on this thread that did not attempt to use the LP 64 plugs thinking they would not load on their 32 bit system? If not how were you fooled?

As far as CW being dishonest or confusing things they did not confuse me because I read up on those plugins on the CW site so I would know about them.