Comments

PipelineAudio wrote on 8/30/2002, 6:04 PM
metering and plug in latency on any dx app is like eating a whole Dunkin's worth of SucksDoughnuts

one day maybe theyll get this right
Geoff_Wood wrote on 8/31/2002, 9:37 PM
But it is fine when that same effect is put on a 'Bus', so it's not just the fact it's a DX plug.
ibliss wrote on 9/1/2002, 8:09 AM
And more importantly, while the display might be 'early', the effect of the comp on the audio is correct.

Mike K
PipelineAudio wrote on 9/1/2002, 10:54 AM
Is it? With a lot of plugs thats not the case. Some things just cant be used, as they always happen in the wrong time.
ibliss wrote on 9/1/2002, 5:06 PM
Is It? Yes it is.
Try this - put something like a single drum hit on the timeline.
Duplicate this track. Pan track 1 hard left. Pan track two hard right.
Adjust the compressor on track 1 to something silly like Thresh @ -15 & ratio @ +10
Switch off Auto Make-up gain in the track 1 comp.
Set Vegas to loop on the drum hit event.
See how the comp meters are way out, the buss meters are dead on, the compression changes the sound of the track 1 drum hit and lowers the peak value on the left buss meter.

Now, go into the Vegas preferences and ajdust the Audio Playback buffering right up the the full 1.000 value.
exit prefs and play the loop again - see how the audio and buss metering stays the same as before, but the track comp now shows meter activity at a different time.

Spooky....
Mike K
ibliss wrote on 9/1/2002, 5:07 PM
forgot to clarify the point of having the two drum tracks panned hard left and right - noticed how they stay in sync?
PipelineAudio wrote on 9/1/2002, 5:41 PM
depends on the plug in
some stay in sync some do not
the db sidechain app is horrible about putting it in the right place

I bet your buffer experiment will give SF some clues on where it goes wrong tho!
pwppch wrote on 9/4/2002, 10:24 PM
Why this happens:

In order to playback with out gapping, audio must be "pre rendered" ahead of the actual time it is heard. This means that for any given signal path the audio must be "streamed". This includes any and all FX. What you are seeing in meters in FX is this. The FX meters repond when they get the audio, not when it is actually given to the hardware. The Mixer bus meters are correct because Vegas can account for this delay due to buffering.

DX plugins can account for this delay, but none do. There is a means for a host to provide a clock source that is sync'd with the actual realtime playback clock. To date, no DX FX vendor support this. (We actually give this clock to the plugs, but none of the listen - yes, even our own plugins.)

I have seen some plugin vendors permit you to set an buffering offset so that meters are delayed. Most host software relys on very low hardware buffering/latency so that the delay is very small.

Peter




Geoff_Wood wrote on 9/5/2002, 12:24 AM
How about an invisible automatic pluin test when a plugin is 'mounted' to adjust this where possible, or is each plugin unique in the way is implements he offset ?
pwppch wrote on 9/5/2002, 9:02 AM
Not possible, because plugins that permit the user to set a buffering offset use a non DX plugin method to accomplish this.

There is no way to tell a plugin to use a fixed offset for its UI/Meters/Etc generically. The only mechanism is to use the master "reference" clock that a host can provide.

Peter


PipelineAudio wrote on 9/6/2002, 12:38 PM
The host clock thing sounds promising!
pwppch wrote on 9/13/2002, 7:27 PM
Just have to get the plug in vendors to support it.

Peter
oddboy wrote on 11/3/2002, 5:11 PM
After reading this its still unclear if this is only visual and the audio is processed correctly or not.

also, is this true in Acid as well? Or are you implying that it is true in all applications that use dx
pwppch wrote on 11/4/2002, 1:18 PM
Audio is processed correctly (though I know Pipeline will toss out a disagreement here.)

The meter offset I explained.

If a plugin does not follow the DX standard, then it can insert silence or useless data into the stream that can cause audio shifts.

Peter
Rednroll wrote on 11/27/2002, 10:02 AM
I just did some catching up on this post, when I just experienced this for the first time using a track insert compressor. WoW!!! these meters are really off. Infact they're useless and inaccurate on top of that. Why even have them if they're not useful? Just so I can look at the pretty bouncing colors, and eat up additional processing power? Not only is there a huge time delay, they don't even seem to be responding to half the audio going thru them. They're 3dB off in level also. Just put a single track of audio in Vegas, and use the SF track compressor. Now if I have a sinewave that is normalized to 0dB and the track compressor threshold is set at 0dB, and the channel fader is set at 0dB, then the master fader should read 0dB shouldn't it? Well Yes it does like it should, but the compressor input AND output meters read -3dB.

If you're going to give me a feature that just randomly bounces on my computer screen when I play audio, please make it something useful like Brittany Spears or Shikera dancing around nude to the music I'm playing......at least that would be entertaining.

"The FX meters repond when they get the audio, not when it is actually given to the hardware."

Peter,
I have a copy of Cool Edit Pro 2.0 on the same PC I have Vegas on. The Track insert meters are pretty responsive AND ACCURATE in Cool Edit Pro, using the same DX plugs in each app. Maybe you can call Cool Edit's tech support and ask them how they where able to accomplish, what you are saying is not possible until DX developers support it. Here ya go, tell them Red sent ya...
1-480-941-4327