Sidechaining success in Vegas!

Angels wrote on 2/25/2003, 12:50 AM

After some digging around, I found this:

http://www.db-audioware.com/dbd.htm

It's compressor/expander with a side-chain function that works great as a compressor/expander/ducker. While the author claims the sidechain has too great a latency in Acid, I've tried it in Vegas 4 and it works really well.

You use one on the track you want to send the control signal from (with no processing if desired), and it gives you 6 chain channels to direct to other instances. You can have one source signal control multiple destinations. You can control a track from another track, a bus from a track or even a track from a bus. The response time is great.

21-day full trial on the demo, so you can really try it out ($39 to purchase). Other than the TC Native bundle costing a lot more, I don't know of any other way to do this kind of sidechaining. If any of you do, please let me know.

This has made my work a whole lot easier: a few less volume envelopes to draw...I'm going to check out the other plugs.

Angels

PS1: I don't work for them, or have anything to do with them! I haven't even actually bought the plugs yet.

PS2: Foundry should seriously consider licencing this gentleman's technology and incorporating it into their next upgrade package; it's sorely lacking in Vegas 4, and people have been requesting it for a long time.

Comments

PipelineAudio wrote on 2/25/2003, 1:21 AM
oh the agony of the DB Sidechain plug...this ones been brought up a few times in the forum.

Seems to work super terriffic, for ducking music when the narrator talks in audio for video...we used it with great success in our hobby video, www.psychicflyingmonkey.com

however for pulling the old sidechain tricks, like, kick drum controls bass or snare drum ungates guitar, it seems to happen at the wrong time, and no amount of futzing seems to get it to line up right....soooo close, but yet so far :(
Angels wrote on 2/25/2003, 1:46 AM

Funny I did a search through this forum on the subject before I posted and came up empty. Anyways, I did some timing tests with this plug and it seemed to work very tightly time wise. But the mix wasn't very heavy, with only a few audio tracks playing at once. I'm going to try again with music material and see if there's problems there.

Thanks for pointing this out. BTW: have you tried this plug lately in Vegas 4? Perhaps something's changed there?

Angels
PipelineAudio wrote on 2/25/2003, 2:05 AM
actually I havent tried it in quite a while...I guess I better see again, Ive been DYING for a sidechain!!!

http://www.sonicfoundry.com/forums/ShowMessage.asp?MessageID=90315&Page=0

billybk wrote on 2/25/2003, 7:02 AM
BTW, the db-audioware plugs were updated last September. As a registered user, I even got a courtesy email from Dave Brown, informing me of the latest update.

Billy Buck
Angels wrote on 2/25/2003, 8:37 AM
Pipeline: you tried them in February 2002. They were updated September 2002. Try the new ones.

SonyJEV wrote on 2/26/2003, 12:44 PM
For those of you analyzing these plug-ins, remember to make sure that if the playback audio seems okay, that rendered audio does as well. Typically rendering will use different (larger) buffers than real-time playback and I've not been able to convince myself that these plug-ins really work (or not) in all cases with the rather limited experiments I have tried.

--j
PipelineAudio wrote on 2/26/2003, 5:58 PM
Ok I made a simple test. I put a sin wave up on one track put the db plug on it set to receive and put another track up a metronome click and set it to send
heres the results:

1. I set the metronome tracks db plugin settings as nuetral as I could get ( threshold at zero, gain zero ratio 1:1) rendering a file here with the metronome solo'd did NOT result in an exact duplicate of the original. To avoid this by putting the plug in bypass no longer sends to the sidechain so that wont work

2. The sidechain send level follows the track volume level in vegas...VERY bad!!!!!!! VERY VERY bad. Theres been lots of posts in this forum about where vegas' send and buss fx are in relation to the faders, newer versions of vegas fx seem to be pre fader, while the DB send is post...
In this case if you had your levels set the way where the sidechain action was working correctly, but then later say decided to turn the kick track up ( while the kick was SENDing to the bass) your settings would be all screwed

3. In order to have measurable results with this test, because of # 2, I panned the metronome hard left and the sine wave hard right. I rendered the file and it did appear that the plug was working at the right time ( actually with the attack time at zero it took 2 mS for the full duck to happen, but close enough for me)

4. Thinking this a success I put up a kick drum and bass track. Once useable sidechain action could be achieved, the result was yucky clicking and popping artifacts left and right. I then ran those same two tracks to hardware to try it on a real world compressor and they turned out fine
Angels wrote on 2/26/2003, 8:26 PM
In response to Sonic JEV:

I'm personally using the db compressor as a sidechain ducker for VO; but after your post I tested using extreme settings (fast attack, deep compression, fast release) and the rendered track seems to be chopped up by the ducker the same way (or close enough for my purposes) as the real-time playback. I'm happy to find that It'll be good enough for me to use as it will save me lots of time.

In response to Pipeline:

Wow! Thanks for the Xtreme testing! By point:

1. Confirmed: the compressor is not 100% transparent with neutral settings; however I can't hear it and I would challenge any hardware compressor to be technically transparent; I don't know how the other software ones fare. A more important issue for me is that there's about 145 ms delay that's not being compensated for by Vegas. I suspect that delay is there to provide the send signal to a sidechain in time for it to be effective.

2. Are you using Vegas 4? Because on my system, it is pre-fader. The only change occurs at -60 db where the track is completele muted, including the send signal. From + whatever to -59.9, the send signal is unaffected by the volume control. And at -59.9 db, the track that's sending is totally inaudible at the main output, while still sending full to the sidechain.

3. 2ms = 88.2 samples; definitely the delay I found (145 samples = about 3ms).

4. Haven't tried any time-sensitive material yet, so I can't comment. As for popping and clicking, I'm hoping it's not your now legendary, world-renowned glitching problem resurfacing ;)

It would seem that ultimately, Sonic Foundry may have to be the one to do a proper implementation of this technology for it to be perfect since the send time from source to destination has to be included in Vegas' overall buffering scheme. Or perhaps there's something db can do to address the issue.

For VO use, the db-comp does the job. When I find the time, I'll test synchronized use in a musical context. But I'm pretty sure it's not going to work well as 145 ms of delay is enough to throw a groove off, never mind the control of that groove; and there's no "dial-in" delay compensation available.

Angels
PipelineAudio wrote on 2/27/2003, 1:10 AM
makes sense how I am seeing some of this wrong. Now I dont know that any software compressors are transparent in bypass mode, but in reality, the process of sending to a sidechain should NOT affect the sending track

this is vegas 4, and youre right, it is when I turn the volume all the way down that it no longer sends. But again we need to have a way of sending that works, not sure the solution here, but if I only want to hear or render the sidechained track, there needs to be a way to do this. It seems that if you put the sending plugin on an assignable fx then send to it after clicking pre fader you can get around this

yup, my 2 mS was an approximation, yours is probably close

the clicking and popping has always been there since vegas 3, its just the comp remping up and down without some sort of smoothing algo I think.

SAW used to be able to do this I think, with its internal effects...it would be cool if SF could pull this off, but Id WAY rather they concentrate on fixing all the known vegas 4 bugs right now
dbaudioware wrote on 2/27/2003, 6:50 AM
Hi guys,

It's probably worthwhile explaining how we have implemented sidechains. Basically, we bypass the Vegas routing completely, and pass the audio buffers between the source & destination plugins.

This means we are completely at the mercy of the host application, Vegas. We can't feed audio between two tracks quicker than Vegas sends it to our plugins. If Vegas uses small buffer sizes internally, everything works OK. But some hosts will force large buffers for efficiency (ACID, for example, uses large buffers to allow all that realtime timestretching stuff). Sometimes rendered offline processing also uses bigger buffers.

So unfortunately, your mileage will vary. We do the best we can in the architecture provided, by bypassing it with our own sidechains. But we can't force zero latency. At the moment, sidechains work great with ducking and other non time sensitive applications, but synchronised effects require you to copy the trigger track and tweak it backwards in time to adjust for the latency.

One final tip - sometimes swapping the ORDER of the two tracks on the screen will improve latency! The host application generally processes tracks in turn, and you want the trigger track to be processed BEFORE the target track.

Aside: we're about to release a major new plugin product which includes lots of new sidechain toys - sidechained multiband compressors, sidechained filters and more. We'll take your very valuable feedback into account during testing. There might be a few tricks we can perform to improve the latency a bit further...

HTH,
Dave Brown
www.db-audioware.com
SonyJEV wrote on 2/27/2003, 12:17 PM
Thanks for chiming in Dave.

I suspected that you must be passing audio between plug-in instances (actually can't imagine what else you could do) and that there would be potential gotchas with the order of processing, buffer sizes, and so on.

Thanks to Pipe and others for your experiments...

--j
PipelineAudio wrote on 2/27/2003, 1:10 PM
man that was cool of Dave B. to show up!
Angels wrote on 2/28/2003, 1:56 AM

Thanks for the informative post, Dave! One question:

Why is there a 145 sample delay in using the Compressor, even in neutral settings as a send device? Is this to gain a little response time at the receiving end of the sidechain? If so, maybe this kind of buffer adjustment should be user adjustable? Or maybe that's not possible. Also to consider: maybe having a transparent send device available who's only job is to send.

Looking forward to future developments.

Angels

PS: Sonic Foundry: any chance you might lend this man a hand when it comes to this whole buffering issue?