I can HEAR that the plugins are actually bypassed when I engage the bypass, but why do the various plugin GUIs still show signal - as if they are still processing signal? Doesn’t this waste CPU?
On the contrary, this is exactly the idea of Bypassing in the Master Section: processing still happens, so that if you un-bypass, you can hear the sound with no latency and crack at transition.
If you want to put the plugin completely Off, you can Control + click on the slot.
Hm, OK, this explains the behavior. Thanks, Philippe!
I wanted to bring this back up and ask, since we’re in WL10 now, did this ‘Control + click bypass on each plugin slot’ function go away, and even if not, can it be applied to the overall Master Chain bypass? hen I try Command + bypass, or Control + bypass on MacOS, it doesn’t seem to bypass the plugin processing.
This is a side effect of the way bypass works: the audio is still processed by the plugin, but the signal is not merged to the stream. Why so? To provide gapless A/B when toggling bypass.
This could be improved, actually, for some VST3 plugins.
How fortunate to find this discussion active today!
I’m running out mastered files with a de-esser as the first plugin in my chain. (The de-esser is a 32bit audio precision). If I bypass the plugin, and render the audio, it does not create the same audio as if I remove the plugin but leave the plugin slot, and does not create the same audio if I remove theplugin and the plugin slot from the chain completely. This tested with a file comparison of the rendered audio files.
If I flip the phase on one file and measure the summed output I learn the following: The audio difference between having an empty plugin slot and removing both the plugin and the plugin slot is approximately -90 db at the first minute of the rendered files and decreases to -160 dB after a minute of audio, and then to an unmeasurable difference after about 3minutes of rendered audio.
The audio diffference between having a bypassed plugin and removing the slot and plugin displays a similar sliding difference.
Given the sliding nature of the differences, I am guessing that it may be a timing difference of the rendered samples as much as a difference in the quantized values. Likewise, while I am creating 64b floating rendered files, having a 32bit plugin (even bypassed) may alter the sample values passed to the next plugin in the chain. I’m not really sure how to test these possibilities. My de-esser is sitting first in the chain, and I would hope that the bypassed 64bit samples would be the same as the 64bit sample values in the source file.
Auditioning the rendered files one can quickly hear that removing the plugin and slot produces more transparent audio than either the bypassed plugin, or rendered audio with the plugin removed from the slot but the plugin remaining. My impression is that the version with one less plugin slot is wider in stereo width and has better presence in the vocals. Unfortunately the only way I know how to remove plugin and slot is to save the plugin chain with the empty slot and recall it.
It would be useful to have a tool where I could remove a plugin and its slot from the chain without having to save and recall the whole chain.
I could not find a control+click behavior that would do a hard bypass around the plugin as described in this conversation. If enabled, it would still be critical for rendered files to correctly compensate for latency differences between the hard-bypassed audio and the version with an active plugin.
I doubt that. You could render both ways and compare the audio files.
Actually- that’s what I did. Rendered and a/b auditioned on separate tracks the diffences are audible. Here is what the computer says:
File comparison between plugin chain with an empty slot vs plugin chain with plugin and slot removed is 8160670 differences.
Likewise comparison between bypassed plugin and chain with plugin removed (Empty slot) is likewise 2480966 differences
File comparison between bypassed plugin and file with plugin-and-slot removed is 8195424 differences.
Granted, the differences may go away when dithered 16bit signal, (I’m not going to check this today) but what I’m rendering here are inter-masters which will be used for more processing before final ISL and dithering, and this brings me to my final point:
I LOVE Wavelab 10. And one of the things that sets it head and shoulders above other workstation software is the ability to work with double-precision audio, that the high precision is carried through the temp files, and is passed through the DSP chain and is available to other processes.
When I upgraded to Wavelab 9.5 I absolutely got what I was seeking: a step up in audio precision and realism that I had not been able to get before. I have used other, much more expensive --software in the past (rhymes with Decoy-ya), and the digital fidelity of Wavelab 10 is something that affords me a competitive advantage. At times it has been a frustrating effort to get here. The Steinberg reps and plugin manufacturers I spoken with frequently confused 64bit audio precision with 64 bit operating systems. Some reps told me that it was impossible to get 64bit audio data through a VST2 plugin (not true). My only desire is to make the high-precision methods I’ve developed easier to use, and as a service to the art of Audio, improve the available quality of audio DSP to other users. Ultimately, with enough bits and samples, we ought to be getting pretty close to analog one of these days.
1 Like
Is it possible the differences are a result of latency? I may have missed this, but how exactly are you comparing the results?