Mixing with external gear with Samplitude Pro X5

[pcrecord]

Mixing with external gear with Samplitude Pro X5

Thanks to jmizz15212 Films J-jigga for posting a question about using external gear while mixing.

In this video I show how to use the FX send and receive fonction of Samplitude. (also available in previous versions

Credits : https://www.telefunken-elektroakustik.com/live-from-the-lab-season-3 Will Evans - "Me and My Crew" https://www.youtube.com/c/WillEvansMusic/videos

 

[kmetal]

I enjoyed this. Its funny, some well known engineers still use those alesis verb units.

One concern i always have with hardware effects is if the delay compensation is working to sample accuracy. Just curious if you've ever tested this in Samp.

 

[bouldersound]

...delay compensation is working to sample accuracy.

I'm not sure what you mean by this. Internal effects have inherent latency that can be addressed internally. Outboard effects may have some latency, but the software has no way of detecting it, and it's likely to be very small since they're dedicated hardware units that don't have to share processing with anything else.

 

[kmetal]

I'm not sure what you mean by this. Internal effects have inherent latency that can be addressed internally. Outboard effects may have some latency, but the software has no way of detecting it, and it's likely to be very small since they're dedicated hardware units that don't have to share processing with anything else.

Protools and logic have delay compensation for outboard hardware inserts. Its compensation for the ADDA conversion involved with using the external effect. If the effect has its own lantency like a digital effect connected via analog, im not sure it can compensate for this.

Take an analog eq for example. Your going DA from interface, thru the eq, and back into the AD of the interface. If the interface has a 4ms RTL (round trip latency) your new eq'd signal from the hardware would not line up with the source track. This would cause phase cancellations. The delay compensation is supposed to compensate for the RTL from the conversion, so things line up.

I don't believe it can dectect a digital ob units internal latency, so i "presume" you would have to manually set an offset for it, or connect digital peices digitally.


I brought this up because a podcast with chuck zwiki, (NIN, Rembrants) mentioned this as a big issue he had in logic, since he's hybrid and uses racks of outboard. He worked with logic to make a pluggin to fix this.

As an aside he also mentioned there was a time where he would get different i/o latency via usb and fw interfaces, when he restarted his machine. This further complicated his mixing and tracking. He solved that by using a pcie based motu setup. So im now a bit paranoid that usb interfaces may still exhibit this behaviour upon restarting.

 

[bouldersound]

Protools and logic have delay compensation for outboard hardware inserts. Its compensation for the ADDA conversion involved with using the external effect.

Why would that be different from the ADDA conversion of overdubbing a live source over an existing track? If an overdub is recorded without an offset, then an effect should be captured without an offset (other than the outboard's own internal latency).

 

[kmetal]

Why would that be different from the ADDA conversion of overdubbing a live source over an existing track? If an overdub is recorded without an offset, then an effect should be captured without an offset (other than the outboard's own internal latency).

Right if the delay compensation is working accurately, it will line up without offset (manual offset would be for compensating the hardwares latency if it had any).

The problem is delay compensation doesn't always work accurately.

There has to be compensation to line up the existing audio, with the re-converted audio from the hardware box. Otherwise the newly recorded sound would be late, subject to the interface latency.

If you tracked a sound coming from your speakers with a mic, to a new track, they would not line up sample accurately. If you subtract the ms of time from the sound actually moving between mic and speaker, you've got the time it takes to DAAD convert.

Before delay compensation you were forced to use hardware monitoring so you were singing/playing in time when overdubbing. Or you used dsp in the interface.

This was a big deal for PT users when PT introduced hardware inserts, they didn't always have it. A hardware insert, is different in PT than just a regular aux. Tho PT delay compensation is still iffy according to what ive heard from even bigger name engineers.

I don't claim to have a deep understanding of the topic, but i know its something that can be an issue.

 

[bouldersound]

My point is, if an overdub lines up correctly then a hardware insert should be the same. To the DAW they're essentially the same thing.

It would be interesting to run loopback tests on some of our systems.

 

[pcrecord]

Hum interesting guys !
I haven't thought of checking this.
I guess if something wrong had gone by, I would have heard phasing issues which is not the case here.

 

[Davedog]

This latency is always an issue when re-amping something in PT. Sure the latency can be controlled through the use of the delay compensation, but it does not always work like you think it should especially in round trips from a digitally captured source out to analog of some sort and then back as a newly minted digital capture. It's funny sometimes....You get the real time monitoring through delay compensation down to a usable number when capturing the track and then when you listen back it's on another planet timewise. And this is after making sure your start/stop numbers are correct. Another interesting aspect of digital recording. I imagine that the scenario that Chuck Zwiki is dealing with is importing lots of sources from different media into a session.

And yeah...I get that you'd think that once the source track has been digitally captured and converted that anything you might do to it in the future would have no effect in the delay world.....but that's not always true.

One thing I have found....when you try to reamp a track that has been edited with the elastic audio in PT, all bets are off. Something in the elastic audio part wants to refer back to it's original position in the track no matter what your compensation is at when you try manipulating it through a round-trip.

 

[kmetal]

My point is, if an overdub lines up correctly then a hardware insert should be the same. To the DAW they're essentially the same thing.

It would be interesting to run loopback tests on some of our systems.

I agree it would be interesting to do a loopback tests.

I think the difference in an overdub is the overdub just needs to be sync'd with the existing tracks, but a loopback has to be in sync with itself. So on an overdub you can delay the tracks enough to compensate for the AD conversion, and everything hits the daw at the same time.

With a loop back the existing audio has to line up with itself, after the AD conversion. This means you have to delay the existing tracks twice as long, to compensate for the DA and AD. So the loopback has time to AD convert, and line back up itself on another track.

One is just syncing input, the other is syncing an output/input combo. In an overdub the DA latency isnt time sensitive to the session timeline. no matter how long the DA takes, as long as the AD signal meets it there is no issue. With the loopback, the DA signal already has a point in time in the session, its got to meet up with itself after the AD, as opposed to meeting up with a fresh signal, that didn't experience a DA conversion before hitting the AD on the way in. An overdub just compensates for the latent input signal, the loop has to compensate for the latent output, and input. In an overdub your only printing an input signal.

That's how i think about it, tho im not sure its completely correct.

 

[bouldersound]

Since a person playing an overdubbed part is hearing the playback, the resulting audio timing on the record side of the DAW is a consequence of output latency plus input latency, just like an effects loop.

 

[kmetal]

Since a person playing an overdubbed part is hearing the playback, the resulting audio timing on the record side of the DAW is a consequence of output latency plus input latency, just like an effects loop.

Your not re-recording the output signal. So you just delay the output to sync with input on an overdub.

With an effects loop it can't be that simple, you can't just delay the output to line up. The output is the input.

Think about it. How could a track in a session line up with itself, after 4ms of input latency? It would always be 4ms late.

 

[kmetal]

In an overdub how much delay used by the delay comp doesnt matter, as long as the input is in time. In a loop it has sync with itself. There's 2x the conversion time in a loop because its the same track.

Overdubs are parallel conversions, a loop is conversions in series.

 

[bouldersound]

Your not re-recording the output signal. So you just delay the output to sync with input on an overdub.

Except the performer is playing to the output. The performer is timing their performance to the output, so output latency gets incorporated into the performance, then input latency is added to that.

 

[kmetal]

Except the performer is playing to the output. The performer is timing their performance to the output, so output latency gets incorporated into the performance, then input latency is added to that.

Right. So the output latency could be 15 sec, and not matter because the performer is responding to when they hear it.

On an effect send if there was a 15 sec output latency then the unit would receive the singnal 15 seconds later than it actually is on the timeline, which is important on the effect send case, because the send needs to line up with the original signal at the same point in the timeline. In an overdub your performing to the delayed signal. You just have to line up the incoming AD signal. In the send the device is "performing" to the non-delayed signal. The daw has to line up both the DA latency and AD latency to the original signal the daw is sending from. Its got to compensate for both. An overdub just has to compensate for AD latency. An overdub is relative to the delayed DA signal, the send effect is relative to the absolute signal from the send track.

The send track has a fixed point on the timeline, so any latency incurred is relative to that fixed point in time. With the overdub it doesn't exist until after the DA, so it only needs to be in time relative to the DA delayed signal.

The "stopwatch" starts counting when the listener recieves the signal for an overdub. It starts when the daw sends the signal for an effect send.

 

[bouldersound]

Right. So the output latency could be 15 sec, and not matter because the performer is responding to when they hear it.

But it would matter. A hardware device is also responding when it "hears" the signal just like a human. In both cases, human and hardware, they don't start processing the output signal until they receive it. On a technical level, there's literally no difference.

 

[pcrecord]

When I get time, I'll make some tests..

IF the software is intelligent enough, once you hit stop after recording round trip, it aligns the audio data to compensate for the possible delay...
Or AD and DA converter might be so fast now that it doesn't mather.. but I guess we are doubting it..

 

[audiokid]

I did these test years back using many world class converters. When mixing with outboard, I eventually moved towards two DAWs and never looked back. I learned a great deal from it. I avoided round trip processing and talked about this. Long story... Once ITB, stay ITB.

 

[kmetal]

But it would matter. A hardware device is also responding when it "hears" the signal just like a human. In both cases, human and hardware, they don't start processing the output signal until they receive it. On a technical level, there's literally no difference.

When the hardware hears it is the same as the human would, yes. But the effect needs to line itself up with itself, the overdub need only line itself up with what its hearing. An overdub doesn't line itself up with its own pre-conversion signal, it doesn't exist yet.

If the effect hears the signal 15 sec late, even if the AD latency is compensated for, its still printing the new signal 15sec later than the original is in the session. The effect send needs to travel "back in time", the live overdub need only stay in time with the post DA signal.

The difference is what in the session the new signal needs to align to. That's where the compensation is different. The effect send needs to compensate a round trip, to line the signal back up to itself. The overdub just needs to compensate for the AD conversion.

If there wasn't a difference, why would there be a dedicated "hardware insert" function? You would just use a regular bus, and the recording delay compensation would be enough. One is a one way trip, the insert is a roundtrip. They can't be the same, its two different processes.

 

[kmetal]

When I get time, I'll make some tests..

IF the software is intelligent enough, once you hit stop after recording round trip, it aligns the audio data to compensate for the possible delay...
Or AD and DA converter might be so fast now that it doesn't mather.. but I guess we are doubting it..

The software is supposed to be intelligent enough to sync it in the session to sample accuracy. Logic and PT, aren't always performing the task properly. Its a known issue.

Also interesting is the latency occured due to a digital outboard vs analog, due to the additional conversion in the box itself. I wonder if that latency can be compensated for by word clock, or if you have to manually set an offset. Im not sure there are any issues of this nature if the effect was connected digitally. I set my cousins apollo and eleven rack up via spdif for his re-amping. It avoids conversion and i presume the latency issues.