CPU Spikes - VST Performance - Nuendo 4.3

Stillwell Audio Plugins Bombardier
1

Hi, everyone!

I came across Bombardier a few weeks ago and I must say I feel this plug-in just might be the answer I’ve been looking for.

I use it as a “Whole Mix Glue” at the very last Stereo Insert slot. The moment I turned “Oversample” on, it seemed like I’d been mixing through it from the very beginning. Of course, I had another compressor in that same slot before, but it was Bombardier in Punch-Bomb mode that gave me the best results. Very little adjustments were made to the “Glue” preset.

However, there are disturbing glitches going on for me. Here’s a brief description of my All-In-The-Box setup:

E6600 - Core 2 Duo - 2.4gHz, 4GB RAM, 965G Intel Chipset on Gigabyte DS3 Mobo. All SATA drives, including a RAID-0 for flawless audio streaming. Texas Instruments PCI-firewire for Audiofire 12 by EchoAudio interface, nVidia GeForce 8400GS.

This session I’ve been working on is 24 bits/44.100Hz. I’m running Nuendo 4.3(x86) on Vista(x64) and all plug-ins in their x86-version.

The biggest problem are the CPU-Spikes I’m getting during playback. Nuendo’s VST Performance display shows 60% before inserting Bombardier and goes up to 80% when I hit the “Oversample” button. Such increase is expected and everything still seems to be under control, except for those CPU-spikes that take place at least once, breaking the audio up. I have to stop the audio engine and restart it again to get back to 80%'s little margin.

I’ve tried setting the latency to the maximum available value and closing every single window to spare video resources. I also tried mixing with huge audio stems to give Bombardier some headroom, but the glitches are still there.

I took some notes that might be helpful with Steinberg VST issues:

  • Bombardier Delay Compensation is set to 0 at Plug-In Information Window. Other heavy processing plug-ins I own show quite big latency values here. Nuendo’s Operation Manual briefly describes it on page 170. This could be it;

  • Release Mode sticks to “Bomb” after double-clicking it. And whenever the session is saved, it toggles back to “Fast”. Also “Punch” points back to “Firm”. It happens when I restart the audio driver from inside Nuendo as well. I never tested what they’re really doing cause those audio break-ups have been giving me headaches… I’m so close to finishing this mix… this could be a GUI-issue-only;

  • Preset Save works, but the presets don’t show in the plug-in preset list. I suspect they’re saved for the session’s list only. “Mode” and “Release Mode” are saved incorrectly, though. This appears to be related to the previous reported bug.

    Scott, please! HEEEELP!

    Thanks for your attention,

    Leo

2

I can see no reason why your CPU use should jump 20% on that machine when turning on oversampling…I wouldn’t consider that to be “expected”. On an AMD Phenom 9850 2.5 GHz quad-core, it’s about 1.4% normally, 4.7% or so when oversampled, when running at an ASIO buffer size of 128. I could see it being roughly twice that much on a dual-core with half the processing power, so 10% MIGHT be reasonable, but I’d expect better performance out of an Intel Core2 processor compared to a previous generation AMD…

The latency value of zero for this plugin is correct. Latency doesn’t necessarily have anything to do with how CPU-intense a process is (although some plugins with large latencies ARE CPU-intensive)…it’s usually about whether or not the plugin needs to “look ahead” in time to see what’s coming. Bombardier doesn’t use lookahead, and so runs as a true zero-latency plugin.

I can not reproduce your problems with the release mode sticking, or with the saved values not restoring properly. There were several updates made to the plugins in the early days of release…have you re-downloaded and reinstalled the plugin?

I don’t have Nuendo, so I can’t test it specifically, but on the hosts I do have, the plugin behaves correctly.

Scott

3

Hey, Scott! Thanks for the answers.

So “Oversample” is not supposed to be all that CPU intensive… humm… it has become a real puzzle for me, then. More than odd is the fact that most of the time I get one clear CPU spike at the very end of the song, at the very last chord, when most of the other plug-ins are not doing much, neither is Bombardier, cause levels are way below the threshold. I’ve looked for automation in other tracks, but nothing is really going on.

I have the latest version of Bombardier and now I wonder if all this trouble(also the GUI ones) could have been caused by a imperfect uninstall…

Please HEEELP! Bombardier sounds so good!

4

The plugin will use approximately 4x as much CPU with oversampling on as with it off (because it’s doing 4x oversampling and thus 4x as much work…) I just have a real problem with that being 20% of a Core 2 Duo @ 2.4 GHz. Your computer should NOT be 1/4 to 1/5 the speed of mine.

Try checking your CPU usage and then adding a default instance of Bombardier…how much does the CPU use go up then? Something’s wrong here, and I’m fairly sure (but not positive) that it’s not Bombardier. If we can find and reproduce a problem here where I can see what’s happening, you can bet that I’ll fix it.

Scott

5

I’ll do that test for sure.

I will also update GForce 8400 GS driver.

I’ll post the results within a few hours.

Thanks a lot!

6

Scott,

I’ve done some testing… I’m not a big fan of attempt and error, but this time I feel kind of lost.

Here’s what I did:

First, I created the simplest 24bits/44.100Hz session possible. Only one audio channel, no plug-ins.

I imported two different unmastered songs to the audio track. Nuendo’s VST meter showed zero at this point.

Inserting Bombardier(default) gave me a steady 5% in the VST meter. Hit “Oversample” and VST meter showed a steady 20%. But this is not CPU, this is Nuendo’s VST Bridge working. And Nuendo 4 forums are filled with VST Bridge complaints…

As I mentioned in the first post, I get at least one VST spike during playback, and this very one tends to happen at the very last chord. To eliminate ‘time-code’ related possibilities(at this point, I would eliminate every detail that would come to mind, no matter how absurd it seemed), I simply moved the files to different start positions now and then. This was how I was able to eliminate ‘time-code’ ways of thinking as well.

But the spikes did happen. And they were not random. I can’t figure out why, but whenever Bombardier’s meters dropped around 8dB from the Threshold, Nuendo’s VST Performance spiked up to 50%. No audible artifacts, of course, it was still way below 100%. I paid close attention to the fact that no spikes happened at the introduction of one of the the songs, with a solid 8dB dinamic range below Threshold point. The spikes happened only after the meters had gone past the Threshold and then dropped.

Both songs have a warm pad kind of sound, so as the last chord begins, the audio meters don’t fade out in a linear manner, actually, they modulate their way down with little bumps in volume. So I can only give you the 8dB range as a guideline.

Please, bear in mind I don’t know anything about Bombardier’s implementation, so I really can’t say if this has to do with Math roundings or fixed equations. I wouldn’t discard Steinberg’s VST Bridge or AudioFire ASIO driver issues, either. I should mention that Vista’s CPU Performance never passed 21%, with or without VST spikes. It’s impossible to determine visually if they’re related, cause CPU Performance keeps changing at fast pace all times.

The GUI flaws I mentioned before are not related to the VST Performance spikes, cause I tested Bombardier’s window closed, too.

Here are the Bombardier parameteres I used the most for this test:

MODE:Punch
Knee: 03.0dB
RMS: 130.6ms
Threshold: 14.31
Gain Reduction Range: 35 -dB
Feedback
Attack 009.91
Ratio 01.19:1
Bomb

I must point out that spikes didn’t happen if I moved the Threshold way too low.

I hope I could help you help me!!!

Thanks for your attention,

Leo

7

Just thinkin’… I quit programming a long time ago… could all this be due to some sort of type conversion or floating point roundings that Nuendo’s VST bridge ‘feels’ the need to translate?

See, that’s why I dropped such subjects a long ago - I’m not good at it.

8

Just had an insight…

Tomorrow, I’m gonna try using Bombardier via JBridge - a VST wrapper that opens plug-ins in a new process, independant from Nuendo’s VST Bridge…

Let’s see what happens…

9

Also, since it’s freely downloadable, give Reaper a try…it has native bridging built in that seems to work really well. It’s what I run and it would be interesting to see the results on your PC so we can compare apples-to-apples with mine.

Not suggesting that you need to change host software, just that it’s a small download and a “known quantity” as far as I’m concerned.

Scott

10

So I did test Bombardier on Reaper, but first things first…

I’ve been using the same audio material for all tests.

Everything from here on refers to tests set to “Oversample”:

“JBridged” Bombardier behaved the same way on Nuendo 4.3(x86). VST Performance at the very end of the song peaking about the same range. No difference at all.

I also tested Bombardier(x64) on Nuendo 4.3(x64). There’s a much better performance here despite the VST meter peak problem. Instead of peaking at 50%, it goes up to 30%.

Now, moving on to Reaper:

First thing I noticed was Reaper’s CPU meters showed a much more efficient usage compared to Nuendo’s. Then again, I don’t have a clue how neither hosts take such measures. Average would be something like 14%, maybe less. But, guess where I got the highest values? At the last chord of the song… it hit over 21% quite often. From this, I would say a side-effect in Bombardier algorithm could have been masked easily. Please, I mean no harm or being impolite. I’m just saying it makes sense to me.

At this point, I noticed the In and Out Bombardier meters were behaving way too different compared to Nuendo’s Bombardier. I tried to load my own preset, but only “Knee” and “Attack” were correctly loaded. I made all changes needed, yet meters behaved way too different from what I was used to seeing. And here’s where I can get a bit more precise about the VST peak issue. My guess took a little spin: I would say problems occur when levels drop around Bombardier’s Output Threshold.

Remember I mentioned the song material had a pad kind of sound that made levels drop with little bumps at the final chord? The VST Performance peak seems to happen when these bumps occur around Bombardier Threshold. It’s like it’s switching something on and off many times or could be making Bombardier process material twice unecessarily… I really don’t know, this is all guess work.

By the way, I still have that “Release Mode” issue, just a little different. Whenever I hit play, it toggles to “Fast”. I hit “Release Mode” twice during playback and it goes to “Bomb” and can’t be changed until I stop and hit play again as it toggles back to “Fast” automatically.

About the credibility of my system… well, I don’t have issues with any of my plug-ins. The worst I can say about it is that Steinberg never solved Nuendo 4.3 VST Performance problems entirely. There are several complaints at their forum.

I hope all this effort will pay-off… I only took such time for testing/reporting because I really believe in your work at Stillwell.

Thanks a lot!

P.S.: HEEEEELP!

11

There is NO difference in behavior from a sound and level standpoint based on the host…the same set of samples in will produce the same set of samples out. Period.

Try this…produce a simple project so you can eliminate external influences, or make a copy of your big project and strip out some of the stuff so we can focus on bombardier.

What I want you to do is to take the track, buss, or master that is misbehaving and inject some pink or white noise behind it at a low level…-60 dB or so. See if the problem goes away. What we may be seeing is floating point denormalization. My plugin traps for that pretty extensively and fixes it where it finds it. Reaper has an option to automatically fix it when it finds it too. Nuendo? I have no clue. Adding noise should raise the level enough so that at least some parts of the plugins (including mine) won’t go denormal. It’s not a fix, and it won’t even necessarily always work around the problem, but if the CPU use goes DOWN when you do that, it tells us where the problem is coming from.

Scott

Scott

12

Also, does Nuendo have a 64-bit (double-precision floating point) processing option? If it does, try turning it on. Reaper is inherently 64-bit signal path internally, as are all of our plugins. Whenever a host doesn’t support double-precision, we have to convert every sample to doubles on the way in, and back to float on the way out. It’s not a WHOLE lot more load, but it is more load.

Scott

13

Nuendo(x64) is 64 native. That could explain the better performance I mentioned before.

I don’t think Nuendo(x86) has a switch to 64 bit processing. I’m pretty sure it’s 32 bit internal-process based.

14

I just created a test project…simplest possible test. New project, add Bombardier to the master, adjust all parameters to non-default values, save, quit reaper, restart reaper, reload project, open plugin UI, done. Please do that with YOUR copy of Reaper, and with Nuendo…both x86 and x64 versions if possible (you are downloading the x64 version of Bombardier to use with x64 Nuendo, right? Does Nuendo x64 support x64 VSTs, or only bridged x86 plugins?) Do ONLY that…no other variables to the test…I just want to see if THIS plugin works, by itself, in those two hosts, on THAT machine.

Doesn’t matter if I use x86 Reaper or x64 Reaper, the plugin loads with all parameters the way I saved them. Doesn’t matter whether release is set to manual, slow, fast, or bomb…it does what it’s supposed to and displays it accordingly.

Let’s tackle this one problem at a time. The issue for the moment is “saved plugin parameters don’t get restored.” Don’t speculate on what you think it may or may not be doing…all that does is make it harder for me to separate out the factual information I can use to troubleshoot from what you’re writing. I appreciate your trying to help, but it’s counterproductive in this case. Stick with observable, repeatable behaviors and report them.

Not trying to be a jerk, just trying to resolve things as quickly as possible for you.

Scott

15

No worries, man.

I’ll stick to the VST Peak problem and we will get to the GUI ones later, if you agree. I totally understand and disaprove being counter-productive.

These tests I made earlier were exactly what you’ve just proposed. Brand new sessions, one stereo track only, Bombardier set on the first slot alone.

I used Nuendo x64 with Bombardier x64.

I have a question for you: do you get more than usual intensive processing as the music material fades out as well? I mean, I probably wouldn’t notice anything if I weren’t using Nuendo.

We’ll nail this!

16

So just doing some recap on what I achieved with Reaper today.

Oversample on:

Average CPU peak: 14%, maybe less.
At the end of the song CPU peak, fading out near Threshold: 21%

17

Gahhh…no.

Please do what I asked. We’re concentrating on the load/save problems first, as those are critical to use. If you’re having problems with CPU use, you can always freeze or render tracks, but a project not restoring the way you saved it could be a bear.

Scott

18

Ok, Scott. I’ll be out for the next couple of hours. I’ll do what you ask when I get back.

And just for the record, as I use Bombardier to glue the final mix, freezing tracks is impossible. The goal is to avoid more bouncing. But I’ll drop it for now.

I’ll be back soon, with more results.

Thanks!!!

19

Right, I understand…I say “you” in the general sense of if someone is having CPU load problems, freezing and/or rendering is quite frequently an option…it doesn’t stop you from using the plugin. Witness the number of people running huge Nebula programs on multiple tracks…

I’ll check back later to see what happens on your machine. Thanks.

Scott

20

Oh, I see what you mean…

General users: FREEZE them if you need, this plug-in is worth it!

Be back soon.