This is particularly perplexing: My native instrument VSTi (I’ll start with my work horse Battery) seem to use an ungodly amount of CPU power on cubase. Literally just enabling the VST and not driving data through it (no sound, but it’s ready to go), eats of 50% of my CPU and even periodically overloads (the little yellow light flashes)… Its a 3Ghz dual core 64 bit intel cpu, so I should be able to load more than one or two VSTi… The native cubase instruments don’t use more than 1 or 2%, and the NI instruments on my protools setup (on the exact same machine) also only take 1-2%, though I know they are RTAS not VSTi… The system is quiet otherwise… Nothing happening in the task manager… Reading the manual doesn’t really offer any help beyond what I’ve said here…
According to the little hash marks on the instrument window, battery and all the other NI plugins are VST3, not VST2… (Fascinating that the halion that comes with Cubase 5 is VST2 plugin
Even the “suspend VST3 plugin processing when no audio signals are recieved” button is clicked, but I presume that only affects things that recieve audion signals, not midi signals…
What I suspect is that since I am running 64 bit cubase on windoze 7 64 bit, the VST3s are really 32 bit and it’s causing some mayhem… Or as a SWAG that’s all I can think off.
I searched through the forums and I see people comment that the video driver seems to make a huge difference with refreshing/etc… So I’m updating that, though it doesn’t cause any trouble with my other DAW stuff (reason, PT 8)…
I’ll let you know if the video driver helps, but any other tips appreciated…
Interesting… It ends up I was pointing to the 32 bit VSTs (as I suspected out loud), and changing my paths to point to the 64 bit versions (as I’m running 64 bit win/cubase), cpu power is running at a few percent now, as it should… So problem solved, but this seems like an easy thing to detect and warn about… But in any case, this was my issue on the cpu itself…
Now I’ve open the Devices->plug-in information menu and clicked VST2.x plugin to add the new path (does it know it’s a vst3 by looking at the DLL? or are the VSTs now forced to be VST2 even if they are VST3?)…
In any case, there is a “missing instrument” in my list, which I’d like to fix… But I can’t delete that line… Rescanning, clicking update, and update plug-in information doesn’t help…
Yeah, the VST bridge that handles 32 bit plugins is not the epitome of efficient. I’ve run a stable 64 bit system (about a month ago I got the last little bit sorted). I removed the VSTBridgeApp completely and am only using JBridge. It’s good that you got it worked out. 64Bit is where everything is headed eventually. To get a good start on it is worth a bit of trouble at the beginning.
The VST2.x plugin paths are a little confusing, and don’t exactly mean “just” VST2.x. They mean 2.x versions for 32 bit systems. But VST2.4 plugs can be 64Bit as well (just like vst3’s can be 32 bit). So for the instrument that you were having problems with, you don’t need to add the path at all if you’re using it already. Cubase should see it as a 64Bit plug without having to add any 32 Bit paths to it (which could potentially make things worse anyway).
Try this to remove the missing instrument. Unclick the checkbox next to the missing instrument. Then remove the VST2.x plugin path to it. Then update and see if that works. Another thing I do that may help is make sure Cubase is using only 64Bit versions of the instruments. For instance, QL Goliath will install both 32 and 64 Bit versions of the play engine. I’ll make sure the 32Bit install is to a generic folder which I’ll just delete after the install. (Doesn’t give you the option to just “not” install the 32Bit version).
Also, if you have plugins under the ~\Program Files(x86)\Steinberg\Cubase 5\VSTPlugins (or something close to that) you can physically remove the .dlls that you are not using, and just update the plugin information when you next open Cubase.
This should at least give you some tips to clean things up a bit.
