Comments

MJhig wrote on 11/9/2003, 6:37 PM
"vv", What's that? Vegas Video 3? It's Vegas 4 now.

Anyway although you don't list the specific plug-ins, even in "VV 3" the plug-ins I've used worked perfectly concerning their processing.

The meters do have latency though in both versions, not fun but adaptable if need be. Still the plug-in's processing is accurate.

MJ
pwppch wrote on 11/9/2003, 9:17 PM
The metering offset in plugins is due to the latency you are using in Vegas.

If you are using Vegas 4, then use ASIO drivers at the lowest latency that is usable on your specific hardware setup. The metering will still be early, but will be far less apparent.

This is the way DX plugins work.

Peter





Arnar wrote on 11/10/2003, 4:02 AM
Thats the cost of full plugin delay compensation i guess
Rednroll wrote on 11/10/2003, 7:07 AM
I Can't complain now, the track compressor meters work correctly in v4.0.
billybk wrote on 11/10/2003, 9:23 AM
"Thats the cost of full plugin delay compensation i guess"

The full automatic delay compensation implementation in Vegas 4 and ACID 4 is actually quite good. From my expereince, it is better than in SONAR 3. I do not use SONY's DX plugin effects much anymore, as I much prefer using my third party effects plugs instead. I always use Vegas 4 and ACID Pro 4 in ASIO mode and normally at 256 or 512 samples. When using my UAD-1's DSP effects (Pultec EQ, Cambridge EQ, LA2A, 1076LN, DreamVerb, etc. ), the ADC in V4/A4 is so tight, that I can continuely loop a 2 measure slice, of a project, and everything stays in sample accurate sync at all times. Try doing that in SONAR and you will get and immediate dropout at the first loop point or at the very least you start to lose your delay compensation. This never happens in Vegas 4 or ACID Pro 4. Yeah, the old SOFO plugins are getitng a little long in the tooth and could use a facelift. The current SONY plugs are certainly quite capable, stable and are of decent quality, especially when you are first starting out, so I would not call it a weakness. But, there are many more specialized and still quite affordable plugins (UA's UAD-1, iZotopes Ozone 3/Trash, the freeeware SIR, SonicTimeworks plugins and Voxengo's Mastering plugs to name a few) available, that take it to the next level, in both sound and interface design, IMO.

Billy Buck
Maxter wrote on 11/10/2003, 11:41 AM
Thanks, ASIO helps
pwppch wrote on 11/10/2003, 10:37 PM
There is no such thing as plug-in delay compensation with DirectShow FX. The host does nothing because it can't. It is entirely upto the plugin to do the right thing.

(Well one company has proposed a mechanism, but it was an unacceptable (and un-needed) solution. It basically made it easy for the plugin vendor to do what ever they wanted and put all the effort on the host vendor, and it was 1) incomplete, and 2) poorly designed. There was no consistency and no assurance that every plugin would implement it correctly, there by forcing a host app to jump through all kinds of hoops to make it work correctly.)

Metering with DX plugins:
ASIO low latency permits a "better" metering experiance, but does not actually fix the problem and provide sample accurate display of meters in DX plugins.

There is a mechanism for the host to tell the meters on a plugin to delay their output. No existing plugin supports it. It would require every DX plugin vendor to change their plugins to support it and every host vendor to provide the plugin with the correct information. Chicken and the egg.

Don't get me wrong, I am all for improving these things, but the likely hood of getting everybody to agree and support standards that exist has proven difficult at best. We do try to promote improvements in behavior between plugins and hosts. I takes time and we have to pick and choose the battles we get involved in.

Peter


Rednroll wrote on 11/11/2003, 8:00 AM
Do we really need "sample accurate" meters anyways? In a mixing/recording environment, my viewpoint is no. Everyone here watches television which is sent at 29.97 frames/second and doesn't seem to complain. So do we need to see meters with a resolution of 44,100 frames per second or even 96,000 frames per second? No...the eye is not accurate enough. The ear is actually quicker in response than the eye, so maybe something inbetween 29.97 fps, and 44.1K fps.

Using meters in a mixing environment in most cases is just a reference guide to ensure yourself that you are not clipping/distorting the signal anywhere. If you're a smart mix/recording engineer you always work with your meter peaking around -6dB, to allow for headroom for the signal to get twice as loud for transients. If you're mixing with signals where you're near the 0dB peak level 90% of the time then I have one question for you. WHY?

Now in a Mastering environment, I would consider sample accurate meters to be needed. That's because the whole idea of mastering is to push the limits of the song so that it will go as loud as possible with causing minimal side effects. So basically you're trying to now push the level to be peaking near 0dB 90% of the time.
pwppch wrote on 11/11/2003, 8:41 PM
Good points.

For clarity, what I meant by "sample accurate" meters is the meter on a DX plugin displays the correct "peak/value" at the playback position time. As it stands now, only our mixer page meters are "sample accurate" in this regard. DX meters are early by the amount of hardware buffering.

With regard to the sampling rate of meters: We always process the entire stream of data, but we look at it in frames. So, in a sense we are "sampling' the actual peak data.

The problem with absolute sample accurate metering in your context is MASSIVE CPU and memory overhead. The higher the resolution of the peak data you generate the more CPU and memory that will be required to keep that resolution. In a master app, sure, this should not be a problem. With 25-50 tracks on 8 buses, this can get expensive.

Peter
(Red: I know you know these things, but this is more for those that don't.)