WL10 resource-hungry ?

To me in C10 and Wl9.5 (maybe also Wl10) the Asio Guard jumped in too quicky to protect.
Consider in preferences to tame it down a bit, and you might have way more asio room and less stuttering.

I have noticed that the plugins cause a great deal of resource usage. Once I have rendered, I remove the plugins and the gauge drops significantly.
LP

I’ve been playing around with WL10 (on a Mohave 10.14.6 system) the past days a lot and could sort out a couple of plugins that drew considerable amounts of cpu. One of the worst is the MAAT DR Meter MkII (v1.6.12), which is parked on my master section and has been a reliable source of information all things loudness to me. All is fine in both Logic and WL 9.5, but in 10.0 it’s a serious hog. The all new processing-load meter unfortunately was not much help sorting that out.

PG - I’m the original OP of this thread and haven’t managed to get WL10 to play the same Montages that worked in WL9. What do you suggest - should I open a tech support ticket at MySteinberg ? Maybe sending the Montage files would prove helpful.

Some stuff has already been improved for 10.0.10
But I would be interested to know what plugins are used in your montage and where, clip, tracks…

I’ll try 10.0.10 when it’s out and see if it’s an improvement for me.

For now, all my plugins are at the track level and are mostly Plugin Alliance VST3’s

Now on 10.0.40 and WL10 is still dreadful performance for me. Even at 512 samples just a couple of tracks with plugins on each causes 100% audio use and constant glitching. This is with an i9 7900x and RME HDSPe AIO. I tried the built-in audio card and it was the same level of performance.
At least in WL9.5 I could solo the track I was working on and that would lower the CPU use, but in WL10 soloing makes no difference!! Now you have to mute every single track to get the same release of CPU usage as you used to be able to get by just soloing the track you were listening to in WL9.5.

The basic problem is the same one I have been complaining about here for literally years: if you have an Audio Montage with plugins on each track, WL processes all plugins on all tracks all the time even when there is no audio file on those tracks. This is with VST3 plugins as well.

So it’s unusable for me right now and I need to get to the bottom of this. What can I send you so that you can take a better look at this ?

I also sense that something isn’t optimized correctly for WaveLab 10 and MacOS. It’s hard to gauge because at my studio where my pretty powerful iMac Pro is, I don’t push the CPU as hard because I’m mostly relying on REAPER and analog gear, and the WaveLab montage has very little plugins running when I use WaveLab. So everything seems fine there.

At my home setup, I rely 100% on plugins and it’s quite easy to overload the maxed out 2018 Mac Mini that I have when using WaveLab at 96k. I had to get an eGPU to make it usable. I don’t think the lack of proper GPU on the mini is the source of the problem, I think that it’s something with WaveLab but offloading the graphics to the eGPU makes WaveLab choke less easily. So for now, that is the fix.

It’s to the point where I’m about to get a new Mac Pro for the main studio and move my iMac Pro to the home setup because I can’t handle the fan noise of the eGPU, and putting it in an enclosure makes it get really hot, and even then, the Mini chokes a little easier than I’d expect.

WaveLab is currently optimized for clip processing. I mean, if you put plugins in clips, these plugins only eat CPU when the clip is read. When using plugin plugins on tracks, yes the plugins are always active.
Therefore, if you use CPU consuming plugins, rather use plugins in clips, rather than in tracks.

What you suggest does not suit my workflow. I need to apply the same processing to multiple versions of a song - so a WL track has multiple files on it which all need the same processing, but every track is different.

It makes no sense for WL to process track plugins when there is no audio playing. There is no logic to it, so current implementation makes no sense. I’ve made this point repeatedly since at least WL8 and nothing ever gets done about it.

My guess is, this is because it is easier said than done…

Hi Richard. I think if you had some degree of success with this in the past it’s possibly because you had one or two plugins that were programmed to cease processing when there is no audio. I’ve found that appears to be the case with most of the Steinberg plugins (except RestoreRig and CurveEQ). They release when a track is muted or there is no audio at a particular point in a track. I haven’t looked very hard, but so far the only third party plugin I’ve found that does this is Blue Cat Patchwork. Which in effect can make any plugins do it because it’s a plugin chainer.

If things seem better in Cubase, maybe Steinberg plugins being used there that are capable of this contribute to the reason.

Worth testing I think.

Thanks for the comment but actually I never use Steinberg plugins - mine are all 3rd-party,

I hadn’t really thought of individual plugins being programmed to release cpu when there is no audio, but that appears to be exactly the case, and it really complicates the whole Track plugin matter.

You could easily test your individual plugins on Wavelab tracks to see if they’re programmed to release, using the Wavelab performance monitor and/or the computer built in CPU meters. That’s all I did. But fwiw, I didn’t find any performance difference between Wavelab 9.5 and Wavelab 10 under the same heavy load on Windows 10, but I don’t doubt that you did. Also I’m not using Mac like you are.

You could then test those plugins (that don’t release) in Cubase to see if Cubase is programmed to release track plugin processing when no audio, regardless of individual plugin programming. I don’t know if that’s ever been stated or confirmed in Cubase, but it should be easy to test, using plugins that have been determined NOT to release on Wavelab tracks when there is no audio.

You could also trial BlueCat Patchwork in Wavelab. It’s not the least expensive plugin out there, but it’s reasonably priced and it should make Wavelab do exactly what you want with your track plugin chains no matter how the individual plugins are programmed. It worked for me on Windows, so I’m only assuming it will act the same on Mac, but worth testing.

There is a VST-3 option (not VST-2) to let the host inform the plugin, that there is nothing to process. But this is not mandatory for the plugin to do so.

Thanks PG, I had no idea. So most of the Steinberg plugins have used this option and Wavelab reports back when there’s no audio and the plugins cease processing. So it’s really up to the plugin maker to turn this on? I wonder if any plugin makers allow the user to turn the option on and off?

I wonder if any plugin makers allow the user to turn the option on and off?

This is not a user setting. This is a plugin capability.

Can a plugin maker use the option in an update if they didn’t use it originally? I assume Steinberg didn’t use it in RestoreRig for a reason, like possible side effect, so why chance it? Something like that?

Can a plugin maker use the option in an update if they didn’t use it originally?

Yes.

Note that WaveLab currently ignore this mode for Sonnox plugins, because in the past, these plugins would crash or do something bad, if WaveLab would activate the so called “silent flag”.

Even solo-ing a track in Audio Montage doesn’t stop the CPU processing of the other track !! The GUI shows the other tracks as muted but from a CPU point of view, they are not. In this regard WL10 is even worse than WL9. Soloing in WL9 disabled all processing on the other tracks but the only way to do that in WL10 is to mute every other track rather than solo one track. That’s many mouse clicks compared to simply hitting solo … PITA.