Cubase not using extra CPU cores for plugins?

I will try it after these last projects are completed. I don’t want to change anything major before things are finished… Soon though. Thanks for the heads up about it. Maybe it will allow me to go ahead and make the transition to 64-bit.

I’m running 6 cores, hyperthreading = 12, Win7 x64 throughyout. I loaded up a bunch of Reverences and although it really didn’t tax my system it seems that if I load them into one channel then they stick to one core. And when I loaded 8 more into 8 groups, 1 each, and sent the single channel to 8 groups (through inserts) then the extra processing distributed around another 8 cores leaving 3 pretty much at 1%. 8 Reverences on one channel gave me ~11% ASIO and adding the 8 groups gave me ~22% ASIO.

Mike.

Since the added audio data were not recorded, the term accuracy cannot be used either way.

Interpolation is approximate, i.e. some form of computational algorithm is employed. The result can be said to sound better or worse, which would be up to the listener. Though, as far as sampling, it cannot be said to be more accurate, since it was arrived at by computation, not actual recorded audio. It was altered by artificial means.

It’s not that I’m not acknowledging your question, it’s just that I thought it wasn’t necessary to answer it after all of the responses you’ve gotten. You already know that these plugin manufactures use over sampling to remove artifacts produced by the digital filters as much as possible from the audible range. The same applies to ADC, synths, and pretty much anything that uses high quality filters. Actually, you will also see metering and limiter plugins using over sampling as a way to interpolate the analog waveform in order to detect inter-sample peaks. But, as far as recording goes, there is nothing you will gain from recording at quad speeds, especially considering the points already mentioned in my previous posts. These plugins you mention already do it internally and that’s all that’s needed for them to provide the highest quality possible.

If you still have questions, search and you shall find the answers to them. I really need to get back to work.

Peace!

I wonder if there are any side effect to them upsampling and downsampling… yet they choose to do it anyway for the benefit of the processing. I wonder if there is a benefit to just keeping it directly at 192kHz the entire time… Hmm.

I believe they are referring to accuracy in processing - not in the original recording. They directly said that the quality of certain “processes” is actually better at 192kHz.

Mmh, from your quote, this can be read in two ways. 1.: In an absolute sense, meaning processing at 192 kHz is always better, and 2.: 192 kHz is better because the design choice was made by UAD to optimize their processing at this frequency for the internal filters. You have to keep in mind they are aiming to emulate an analog preamp/EQ - not aiming for the least artifacts.

“like the Pultecs, the UAD Neve 1073 upsamples incoming audio to 192k in order to get the resolution the numerics required to accurately emulate the filters.”

They obviously imply that some processes are superior at 192kHz.

Before deciding to do my project at 192kHz, I did many many experiments with plugins at all of the different sample rates. Some plugins actually do sound better to me at 192kHz relative to 44.1kHz (it is a very slight difference though - and like I mentioned earlier in this thread, it is debatable whether it is worth the CPU cost). I decided the difference was noticeable enough though that I wanted to experiment with producing an entire album at this sample rate - which is what I have done. I have no regrets about doing this project at 192kHz. It worked out fine… although in the future, I might try working at 96kHz which would be a nice compromise on CPU vs sound I think.

Hi, toader
there’s no need for jBridge to run UAD plug-ins in Cubase 64, everything works great just as it is.

Ahh… cool! Thanks for letting me know. As soon as this current project is finished (very soon) I’ll start messing about with 64-bit. If it works well, I may finally go ahead and make the transition immediately.

What can be done to improve the use of multiprocessors on a mac? Specifically is there any other strategies similar to the PC’ers bios options?

I am in a similar situation in that i running into my asio limits but I have 50 % of my processing power on my dual x quad core machine. Activity monitor is telling me that 50 percent of my processors are idle and cubase is struggling with the project. BTW my latency is set to the maximum 2048 samples. this is the first time i have hit the wall with this machine on any project and everything I searched here only pertains to PC’s. BTW Multiprocessor is turned on.

I understand your point regarding the pluggins and thanks for that info

cubase 6.53

I’m not a Mac user, but my understanding is that the lack of multiprocessing efficiency on Mac’s is due to the OSX itself. Until Apple decide to address whatever issue they have in that area, then I’m afraid nothing you do will remedy the problem you’re running into (which unfortunately seems to be the case for all Mac users). I could be wrong though, so take what I say with a grain of sand.

Hey Jose

Thanks for the reply

I had a very informative discussion with a steinberg canada rep.

It seems Steinberg does not use hyperthreading and the discussion also got into pluggins and there implementation. Not all developers take full advantage of steinberg’s multi core support. generally pluggins that are verson 3 will show an improvement in performance but just because they are version 3 is no guarantee. FWIw moving to 64 bit and upgrading some of my older pluggins has shown am improvement.



I found out that if you download Xcode, apples developer software editor, you can run its preference pane which will then show up in your system preferences. if you now open up that system preference there is a selection which you can turn off hyperthreading - whicm ‘may’ improve cubase’s performance on your machine- but if you are running any video or graphics editing software you will see a significant performance decrease in those applications by doing so. I believe this is 10.6.8 and prior feature only - I have yet to try this yet.

cheers phi

I came to my conclusions by ear from past tracking and commercial release experiences…but, mostly Larvy’s paper supports the conclusion: 48khz is best for legacy machine/systems…and 88.2 is best for new ones. I’ve NEVER preferred 44.1…including once it’s all back TO redbook.

The only part of his paper I don’t “hear”…is the inferiority of 192. To me, it’s just simply indistinguishable. But, I’ve never tracked at it–only heard mixes by the best in the business…same material, redbook, 24/88and 174…96 and 192…redbook, clearly inferior. The others, I couldn’t tell you one from the other, better or worse, if my life depended on it.

Just keep that in mind as you experiment…and ultimately, that’s the only way you’ll answer this for yourself…but, don’t think because 192 sounds better than 44 that you necessarily NEED 192 to hear that difference. I don’t have any interest in 192. I will never track even a demo at 44.1 again. Anything that does 44 will do 48 and sound better. Anything that can do 88, should.