Best way to record I/O plugin

Hi fellow Logic users

What's the best way to record the I/O plugin (the processed signal coming in)? How do you do it? For a single channel, for multiple channels.

Cheers

Murat

The I/O plugin is Logic's version of send/return.

You use it to send the signal out of logic to an external device. No rule says it has to return to that same channel strip/track.

Simply use the audio track with the I/O to monitor and record on a new track using the return input as the audio channel input.

Yup, that is kinda the obvious way I came up with. I wished it was possible to just hit record on the track itself and record there.

Insert points on channels are always after the "tape" (in the case of DAWs, the audio recording), so in order to record an output of an insert process, you have to route it back to the record section (by the ways already discussed).

Yup, that is kinda the obvious way I came up with. I wished it was possible to just hit record on the track itself and record there.

 

Insert points on channels are always after the "tape" (in the case of DAWs, the audio recording), so in order to record an output of an insert process, you have to route it back to the record section (by the ways already discussed).

Yes, that makes definitely sense, if you look at it in the traditional old skool way. That's also how I learned it decades ago :D

I thought that maybe nowaydays DAWs would (should?) be more straight forward. Such a feature would save a lot of "hassles" like routing, recording, then undo the routing again, check latency, clear latency. I'd expect Click-And-Go and it's recorded.

It seems I'm ahead of the future

I thought that maybe nowaydays DAWs would (should?) be more straight forward. Such a feature would save a lot of "hassles" like routing, recording, then undo the routing again, check latency, clear latency. I'd expect Click-And-Go and it's recorded.

Well, signal flow is signal flow, and most DAWs are in many ways architected in the old familiar ways (with some niceties eg offline bounce, bounce-in-place, effectively infinite channels, busses and so on)

As long as you understand the signal flow in Logic, and how to route signals around, then you can usually find a way to do most things. Don't forget there are the less used objects to use, like input objects, as well, which can be useful in some circumstances.

Why are you not realtime bouncing your I/O? Seems excessive to record to a bus track.

hahahaha.... haven't thought about that. Will try that. Finally it'll be the same time used. But bouncing could solve the latency issue.

make sure to ping your latency..

ps the realtime bounce on the master track should be your most accurate option anyways. Just solo the track with the i/o you are trying to bounce and just use the master output bounce.

Thats what I do.

make sure to ping your latency..

 

ps the realtime bounce on the master track should be your most accurate option anyways. Just solo the track with the i/o you are trying to bounce and just use the master output bounce.

 

Thats what I do.

Yeah, definitely pinging

And the measured samples are VERY accurate. Tested it and no phase issue what so ever.

I think that's really the best way, although you still have to re-import the recorded track. But that's done pretty fast.

Depends if the I/O plugin is inserted onto an audio or software instrument track, or on an aux/output.

But yeah, bouncing takes care of many latency issues. Bouncing is the only time Logic compensates for PDC latency when recording.

Depends if the I/O plugin is inserted onto an audio or software instrument track, or on an aux/output.

Not sure what you mean. Please elaborate this comment.

Depends if the I/O plugin is inserted onto an audio or software instrument track, or on an aux/output.

 

Not sure what you mean. Please elaborate this comment.

I hit the quote button to try to answer this a couple of times, but realised there was some holes in my knowledge. So I went away and thoroughly tested recording (the return signal) from I/O plugins (over 200 test recordings!).

Here's how I think it works, depending on which type of channel strip you have the I/O plugin inserted on. Let's start off with an easy one...

Recording an I/O Plugin from an Audio or Instrument channel strip

Simply route the Audio or Instrument channel strip to a bus via it's send, and use another audio track to record from that bus. You can have latency inducing plugins before and after the I/O plugin in you want, but if you want to record a completely *dry* return signal, you'll have to bypass any plugins inserted after the I/O plugin.

With audio/instrument channel strips, you cannot record direct from the inputs you've set in the I/O plugin. You must record through a bus, or you'll get recordings that are a minimum of a roundtrip early.

Recording an I/O Plugin from an Output

Recording a dry return signal from an I/O plugin that's inserted onto an output channel strip only works* if the following tough restrictions are met:

1. You've correctly tested and set your Recording Delay in Preferences > Audio. (see Recording Delay Test)
    
    
   
2. You record direct from the same inputs that you've configured in the I/O plugin. You must record the return signal direct from inputs, you cannot record through a bus.
    
    
   
3. The I/O plugin must be the first latency inducing plugin on the output. Also, you can't have any tracks that route signals through a latency inducing plugin on an aux before the output hosting the I/O plugin. In other words, all signals currently routed to that output must be latency free prior to the output's I/O plugin. And bypassing any latency inducing plugins prior to the I/O plugin won't help, you have to completely remove them. This is why recording an I/O plugin on an output is so restrictive.
    
   Latency inducing plugins on audio or instrument channel strips are fine, they won't affect recording alignment. Latency inducing plugins inserted on to the output after the I/O plugin also have no effect on recording alignment. You just can't have any aux/output plugin latency before the I/O plugin.
    
    
    
   
4. The latency through an output's I/O plugin must be exactly the same as your normal roundtrip, which probably means you can only record the return signal sample accurately when using zero latency outboard (i.e. analogue). If the I/O plugin's latency is higher than a roundtrip you'll get late recordings, and if less than a roundtrip you'll get early recordings.
    
   * If you don't mind a small recording misalignment (due to say 1 - 2 ms of digital processing latency), then you can also record the return from non-analogue outboard that has AD/DA conversion and processing latency. It really depends on wether you want sample accuracy or not and how high the outboard processing latency is.

I personally never put I/O plugins or other latency inducing plugins on outputs anyway, because it's caused me too many (seemingly) unpredictable problems in the past. I've just included it here for completeness, and because the restrictions above can also sometimes apply when recording from an I/O plugin on an Aux:

Recording an I/O Plugin from an Aux - Method 1 (restrictive, record from inputs)

This method also allows you to record a completely dry I/O plugin return signal direct from the same inputs set in the I/O plugin. But exactly the same restrictions (1-4 above) that apply to recording the return signal from an output's I/O plugin, also apply to recording from an aux's I/O plugin (unless you use the easier method 2 below).

So, if you want to use this method, the roundtrip through the aux's I/O plugin must be exacty the same as your normal roundtrip (4), and you can't have any other latency inducing plugins in the signal's path before the aux's I/O plugin (3), etc.

The only real advantage I can see with this method is that it allows you to record the dry signal when you have plugins inserted after the I/O plugin, and you don't want to bypass those plugins (see below).

Recording an I/O Plugin from an Aux - Method 2 (almost foolproof, record via bus)

Simply, send (or output) to a bus directly from the aux that the I/O plugin is inserted on, and record from that bus*.

This is much easier than method 1, because you don't need to worry if the signals you're routing through the aux's I/O plugin have already incurred latency prior to reaching the aux; and you can also freely insert latency inducing plugins before the I/O plugin (on the same aux). Also, you don't need to worry if the trip through the I/O plugin isn't an exact roundtrip, so can also sample accurately record (digital) outboard that has processing latency.

If you want to record a completely dry return signal, just bypass any plugins inserted onto the aux after the I/O plugin (if any).

* You must feed the bus from the aux channel strip that the I/O plugin is inserted on, using the send (or output). You can't feed the bus from an input monitored Audio Track (i.e. Input > Bus), and you can't feed the bus from another (Input) Aux, and you can't feed the bus from an Input Object. This method only seems to work if you feed the bus from the actual aux the I/O plugin is on - this had me baffled for a while.

Realtime Bouncing

For every test I ran, I also soloed the aux or output and did a realtime bounce. Perfectly accurate every single time.

The problem with realtime bouncing, apart from not being able to multi-track record, is that you can only get a dry recording if you bypass all plugins after the I/O plugin, including plugins on later auxes and outputs.

But, if you're pressed for time and need to print the I/O plugin's return when all other methods are out of sync, it'll give you sample accurate recordings every time. They certainly wrote the Bounce code very well.

--------

So that's my current understanding of the subject.

Hope this helps. I think I elaborated.

dD

Am I the only one who finds this oddly complicated? I know I'm an an amateur, but still...

I never could figure out how to record through an external box. Instead I record a dry signal and then, using a bus, record through the box onto a new audio track. Having read this thread I'll now consider a real-time bounce--though I'm not sure how this differs from my original recording method. I wish, though, that it was an easy task to record directly through the box.

Jim

Am I the only one who finds this oddly complicated?

If I cut through all that crap I wrote, I can summarise like this:

If the I/O Plugin is on an audio, software instrument, or aux channel strip then use a send on the same channel strip to route the channel strip's audio to a bus. Use an audio track to record from that bus. That's it.

If you want a dry return signal, temporarily bypass any plugins on that channel strip that are inserted after the I/O plugin.

It get's complicated when you want to record from an I/O plugin on an output channel strip, or when you want a completely dry return signal but don't want to bypass any plugins inserted after the I/O plugin.

Hey there Red Baron--

I'm using the i/o plug on an audio channel. I want to send audio I've already recorded to external compressor & eq boxes and record the result onto a new audio track. Simple, right?

By "use a send," do you mean dialing the original audio channel's (the one with the i/o plug) send knob to its maximum? I've always tried setting this audio channel's output to a bus, and then on a second audio channel using that bus as the input. Is that functionally the same thing that you are suggesting?

Jim

...

It get's complicated ..., ... when you want a completely dry return signal but don't want to bypass any plugins inserted after the I/O plugin.

How about multiple parallel Sends/Bus/Aux configuration?

To throw in yet another question:

Is there a difference between using an aux to record to a second audio channel vs. simply bouncing as suggested by qtherearranger?

Jim

I'm using the i/o plug on an audio channel. I want to send audio I've already recorded to external compressor & eq boxes and record the result onto a new audio track. Simple, right?

 

By "use a send," do you mean dialing the original audio channel's (the one with the i/o plug) send knob to its maximum? I've always tried setting this audio channel's output to a bus, and then on a second audio channel using that bus as the input. Is that functionally the same thing that you are suggesting?

Yes. You could also use the track's (channel strip) Output, but I find it more convenient to use the Send, because I'm monitoring the track with my stereo output.

But, if you want a *dry* return signal, you have to bypass any plugins inserted after the I/O plugin (on the the same track/channel strip). Bypassing those plugins on the audio (or instrument) track won't make things go out of sync. Also, you don't need to bypass ANY plugins inserted before the I/O plugin.

So, ignoring the two right hand channel strips for a moment, exactly like this:

Recording an I/O Plugin from an Audio or Instrument channel strip

Now, just for the full picture, you can also feed the "print" bus with an (Input) Aux or an Input Object (or another audio track with input monitoring enabled).

But if you feed the "print" bus this way, you must bypass any latency inducing plugins inserted onto the audio track after the I/O plugin (bypassing any latency inducing plugins is fine, no need to remove them). Otherwise you'll get early recordings. That's why I recommended using the track Send, to save you from further latency issues.

The advantage of doing it this way, rather than using the Send on the "I/O plugin" track, is that you only need to disable latency inducing plugins inserted after the I/O plugin, which means you can have as many zero latency plugins after the I/O plugin you want, but you'll still be able to record a dry signal without having to bypass those zero latency plugins.

So, you could do it this way if you make sure you don't put any latency inducing plugins after the I/O plugin (on the same track/channel strip), or if you make sure you bypass only the latency inducing plugins that you've inserted after the I/O plugin.

...

It get's complicated ..., ... when you want a completely dry return signal but don't want to bypass any plugins inserted after the I/O plugin.

How about multiple parallel Sends/Bus/Aux configuration?

Can you describe a simple example you have in mind, that I can test?

To throw in yet another question:

 

Is there a difference between using an aux to record to a second audio channel vs. simply bouncing as suggested by qtherearranger?

 

Jim

Bouncing will always give you correct recording alignment (providing you've Pinged correctly), but bouncing essentially means "bounce/record your output", so the I/O plugin's return signal is subject to further plugins/processing on the same track/channel strip, and any other subsequent plugins on auxes, and eventually the output channel strip. The return signal may also be altered by panning and gain changes if it goes through subsequent aux channel strips etc.

So, to get a dry return signal when bouncing you basically have to bypass all plugins that occur after the I/O plugin, all the way up to the very last plugin on your output channel strip.

Red Baron--

Hate to sound like an idiot but...

By "dry return signal" you mean the audio after it's been processed only by the external box (or boxes), correct?

Jim

Red Baron--

 

Hate to sound like an idiot but...

 

By "dry return signal" you mean the audio after it's been processed only by the external box (or boxes), correct?

 

Jim

Correct. The processed signal that's returning from the external outboard. Technically a wet signal I know!

I mean *dry* in the sense that the processed audio coming back to the I/O plugin from the external box hasn't been further processed by plugins in Logic after the I/O plugin.

Hey Red Baron--

I want to thank you for all the info you've provided in this thread. Although I still believe that sending sound to an outboard box & back should be as easy as hitting "record," at least I've learned a thing or two.

Jim

Yeah, it could be easier. Would be great if all plugin's had a bounce button, with Logic compensating for the latency.

But I don't hold out much hope for that..

Logic doesn't even update it's internal roundtrip latency figure when you set the Recording Delay in audio prefs. I shouldn't have to Ping all-analogue outboard because I've already told Logic what my Recording Delay is (aka unreported latency). The I/O plugin should then use that recording-delay-corrected roundtrip figure and report it to the PDC system, by default. Quite an easy fix.

I'm using the i/o plug on an audio channel. I want to send audio I've already recorded to external compressor & eq boxes and record the result onto a new audio track. Simple, right?

 

By "use a send," do you mean dialing the original audio channel's (the one with the i/o plug) send knob to its maximum? I've always tried setting this audio channel's output to a bus, and then on a second audio channel using that bus as the input. Is that functionally the same thing that you are suggesting?

 

Yes.  You could also use the track's (channel strip) Output, but I find it more convenient to use the Send, because I'm monitoring the track with my stereo output.

 

But, if you want a *dry* return signal, you have to bypass any plugins inserted after the I/O plugin (on the the same track/channel strip).  Bypassing those plugins on the audio (or instrument) track won't make things go out of sync.  Also, you don't need to bypass ANY plugins inserted before the I/O plugin.

 

So, ignoring the two right hand channel strips for a moment, exactly like this:

 

Recording an I/O Plugin from an Audio or Instrument channel strip

i-o_plugin_on_a_track.png

 

Now, just for the full picture, you can also feed the "print" bus with an (Input) Aux or an Input Object (or another audio track with input monitoring enabled).

 

But if you feed the "print" bus this way, you must bypass any latency inducing plugins inserted onto the audio track after the I/O plugin (bypassing any latency inducing plugins is fine, no need to remove them).  Otherwise you'll get early recordings.  That's why I recommended using the track Send, to save you from further latency issues.

 

The advantage of doing it this way, rather than using the Send on the "I/O plugin" track, is that you only need to disable latency inducing plugins inserted after the I/O plugin, which means you can have as many zero latency plugins after the I/O plugin you want, but you'll still be able to record a dry signal without having to bypass those zero latency plugins.

 

So, you could do it this way if you make sure you don't put any latency inducing plugins after the I/O plugin (on the same track/channel strip), or if you make sure you bypass only the latency inducing plugins that you've inserted after the I/O plugin.

Just bumping this to thank RedBaron!!

I have just set up 30 channels of outboard processing via a new Apollo 8 + Apollo16 and it has been completely baffling me how to print the i/o without latency. This thread has saved the day

I have to say I now have an extremely complicated mixer setup full of aux into busses etc but with 'hide' and 'track stacks' it is manageable. It would all be so easy if you could just 'record' onto an aux channel rather than bussing it out and back in. Seems crazily overcomplicated but it's the only way it seems to work if you want to multitrack record several i/o returns without weird latency.

Sorry to drag up an old thread but I can't find an answer to what I'm trying to do and this thread seems to be the most in depth explanation on the subject.

I'm trying to route a summing mixer within Logic. Whereby I can send outputs from Logic to the separate channels on the mixer but return it's mix bus back into Logic's mixer.

That way I can get the benefits of the sound of the mixer for use as a sub mixer to colour parts of my mix but still have the main mix bus in Logic so I can keep some stuff clean and have all the benefits that come with a software mix bus.

The way I set this up is to have an aux channel in Logic for each channel on the summing mixer. Those aux channels are routed to ‘no output’ and have an I/O plugin on there. I set the plugin to send to it’s respective summing mixer channel, receive the return of the mixer, ping it and then set its return to ‘no input’

I then have a stereo aux channel for the return with the I/O plugin and I then route that to Logic's mix bus

When I route a track to this it works fine and does what I need it to. However when I use a bus/aux between it, it doesn't and everything returns out of sync.

I'm not at the studio at the moment to check but I very likely had some latency inducing plugins on the group. It's certainly a scenario I will need in the future as I like to group lots of stuff when I mix.

I presume it's because of this....

 

Latency inducing plugins on audio or instrument channel strips are fine, they won't affect recording alignment. Latency inducing plugins inserted on to the output after the I/O plugin also have no effect on recording alignment. You just can't have any aux/output plugin latency before the I/O plugin.

 

dD

Why does this happen? I can put an I/O plugin on a group and it will sync up so why does it go out of sync when it's routed to a different place? At what stage does Logic actually 'nudge' the signal back to get it in sync?

Is there any kind of workaround I can do to get this to work?

I was thinking I could use a 3rd party plugin to put a negative delay somewhere in the chain but as most of these just report a latency to Logic I presume I would still be at the mercy of where Logic will compensate for it?

Is this just wishful thinking?

Thanks in advance