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.
I’ve finally reproduced what you’re talking about Richard. And it happens with Wavelab 10 on Windows too. It doesn’t happen in Wavelab 9.5.
To reproduce make a 96k or 192k montage with 3 (or more) tracks (it’s easiest to make the montage in Wavelab 9.5 because then the montage will be readable in Wavelab 10 too). Add an audio file to each track and stagger the files so they don’t overlap vertically.
Put a plugin that doesn’t use the silent flag (thanks PG), like the built in Steinberg RestoreRig, as a track plugin on each track.
Solo track 1 (this will “mute” the other 2 tracks) and play the first audio file.
In Wavelab 10, the audio will probably be distorted or stuttering and the performance meter will probably be at full scale.
Now while it’s playing, toggle the mute buttons on the other 2 tracks. That should “fix” the distortion and performance meter. The Solo is “muting” the other 2 tracks but apparently not fully (as Richard said). This doesn’t happen in Wavelab 9.5, and seems like it should be fixed in Wavelab 10.
I actually did this with Wavelab Elements 9.5 and Wavelab Elements 10 but I would bet it’s the same in Wavelab Pro.
There’s still the subject of the VST3 silent flag I’m looking at because from what I can tell (somebody please correct me if I’m wrong) Cubase and Reaper don’t add extra programming to force all Track plugins to release processing during silence regardless of silent flag, any more than Wavelab does, so requesting Wavelab to do that seems like an unusual request. Cubase and Reaper just seem to rely on the plugin maker to enable the silent flag, or not, but I think there are a lot of third party VST3 plugins where it was not used (probably including at least some Plugin Alliance plugs). It would be worth testing the Plugin Alliance plugs one by one to see which of them does or doesn’t use the silent flag. It’s pretty easy to tell in a 192k or 96k montage. Then it could possibly be requested of the plugin maker to enable the flag. Whether they would or not is another matter. But if all the plugins used the flag you probably wouldn’t even have to use Solo as long as the files were staggered.
Or you could use your VST3 plugin chains in Blue Cat Patchwork VST3 and all the plugins would release whether they used the flag or not. Although Patchwork has some amount of overhead of it’s own.
Thanks Bob99. I’m actually on Windows also - notsur why you thought Mac.
I’ve just spent an hour today recording a series of keystrokes into Metagrid, that helps me get around this issue. But aside from my main gripe, this “Solo” CPU behaviour feels like a bug because it’s different from WL9.5
P.S I emailed Plugin Alliance asking about the VST3 flag and am still waiting for an answer
Yes it’s definitely a bug because it goes back to the correct state (the WL9.5 state) when you toggle the mutes after soloing.
Well spotted !
Hi PG. Are you able to reproduce this? Will it be fixed? I could try to make an example montage if needed.