this is something that used to work perfectly well in v5:
Rendering a mono file with the “Process in place” activated using any (stereo) plugin in the master section routed the audio through the master fx and placed the resulting audio back into the wave editor window of the original mono file (hence the name “process in place”).
Doing the same thing in v7 forces the creation of a new stereo file, which is quite an annoyance in itself, but it’s even worse that the L and R channels of the resulting file are totally out of phase. This doesn’t seem to depend on the plugins used, for example I got the same results with UAD Cambridge and Waves L1 Ultramaximizer. Am I missing something here or is this really a step back on the WL evolution ladder?
Many plugins don’t have a mono version.
The master section won’t allow the insertion of mono plugins anyway (“Error reported by plugin …: Cannot handle the required number of input channels. Plug-in is switched off.”).
Even if it worked this way, it still wouldn’t explain why the two channels should be treated differently in case of mono files.
I must correct myself about this being plugin independent. I did some more testing and here’s what I’ve found:
UAD Cambridge works perfectly well by itself (i.e. the rendered file replaces the original mono file in its wave editor).
Other UAD plugs (e.g. Dreamverb) make the master level display a single fader only instead of the original L/R layout. This could make sense, but rendering creates a new stereo file, where the left channel contains the processed signal and the right one has the original. Before someone asked this: yes, I can paste the left channel back into the original file, but this completely unwanted exercise should be avoided by actually executing the processing “in place”.
TC VSS3 throws a “serious error occured inside the plug-in ‘VSS3’.” message, does nothing to the original file and doesn’t create a processed one either.
Waves L1+ Ultramaximizer behaves the same way as Dreamverb (i.e. creates a new stereo file with processed/unprocessed channels) with the exception that it doesn’t change the Master Level section to display a single fader.
So, it looks like mono file handling in the master section has definitely changed for the worse. Could we get the old file handling back for “in place” procession of mono files regardless of the plugins used in the master section?
The mono L1 on a mono file works for sure. The phase shift is introduced because the stereo plug is applied to one channel only, instead of both (having internal latency, this affect only one channel creating the phase shift).
I agree with you that WL7 handles stereo plugs in a different way than previous versions (I have the same issue with PSP, for example - no mono version).
If you have it, put a stereo Renaissance EQ first, then all the other stereo plugs you have. the REQ creates no phase shift because has no latency, and allows you to perform your editing without phase shift.
You also could try to push the mono button before rendering.
Thanks, this doesn’t help with the VSS3 error, but at least rendering with L1+ or Dreamverb won’t create new files any more and the original meaning of “process in place” will be retained. Although it’s not a big deal to press that button, I still find it somewhat silly that WL has to be tought that a mono file should be treated as a mono file.
Anyway, the problem is still apparent and the persistent error on rendering for certain plugins should be fixed. It will take some time, because PG is busy working on v7.1 I guess.
I’m not sure whether the “certain plugins were concerned” bit is a reference to your fix or the error in general. My tests showed that the problem exists with certain plugins only, but a proper resolution should apply to all existing and future plugins by routing the mono signal to both stereo channels of the master plugins and placing a summed mono version of the resulting audio back in the wave editor of the original file. Just like it used to work in v5 for any plugin without any problem.
I obviously don’t know how the internal processing was organized in v5, I just guessed it was based on summing the processed signal before replacing the original.
But the point was that it was definitely possible to render any mono file treated with any stereo plugin in the master section with “process in place” activated and getting the processed signal back in the original wave window without any further user action.
No, it was not always possible in 5 (as in 7). Take the StereoExpander plugin on a mono file: a new stereo file is always produced.
Actually I don’t have 5 to test, only 6, but I believe it was the same thing.
You’re absolutely right, StereoExpander does create a new file. It seems that I never used a stereo plugin on mono files that behaved like this, but the ones I did use worked literally “in place”. Thanks for the info anyway, we’ll see how the fixes in the new version will exactly behave. Knowing that there is a workaround for most plugins (although it’s not very convenient) it would be the most important to get a fix for the permanent error on plugins like the TC VSS3, which can’t be rendered using a mono source file at all at the moment.